pilot-db-list

[pilot-db-list] Pilot-db-list digest, Vol 1 #257 - 6 msgs (fwd)

[Scott W. <swa...@my...>]

Date: Tue, 6 Nov 2001 23:23:27 +0100
From: Fab <kr...@bi...>
To: Pil...@li...
Reply-To: kr...@bi...
Subject: [pilot-db-list] 0.3.3.betaC

>	Hello all.

>	So I played a bit with 0.3.3.BetaC version and found some
>things with my Palm Vx OS v3.5 :

>	6 - Reseleting the calculatd field type in the "Database Design"
>view resulted in a "MemoryMgr.c,Line 4359, free handle" error. The new
>field didn't survive the reset. I reproduced the case.


	Thanks for the help, I believe that I fixed this bug.
-Scott

[pilot-db-list] Re:New Mobile-DB Format/Windows Front-Eend

[Chalain Marc<mar...@vo...>]

I'm working on VFS support, after i work on the MobileDB support.
Salut,
Marc.
____________________________________________________________
Faites un voeu et puis Voila ! www.voila.fr 
Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. 

[pilot-db-list] 15000 Pilot-DB Visitors since August 2001

[<aji...@t-...>]

Hi,

We've crossed 15000 visitors since August 2001.

That means approx. 1 new visit every 10 minutes.

Hans

[pilot-db-list] Script Support

[Scott W. <swa...@my...>]

I've been thinking about the future of the scripting abilities in db, and
I realized that I made a few decisions that will significatly impact how
easy it is to extend the abilities of scripts.  I'd like to fix these in
the near future, but they will NOT be backwards compatable.  I assume
that I will need to take care of this internally, so that everyone's
databases don't break.  But if no one is using scripts for anything
other than testing at this point, I guess I'd like to know that too.

	-Scott

[pilot-db-list] 0.3.3.betaC

[Fab <kr...@bi...>]

	Hello all.

	So I played a bit with 0.3.3.BetaC version and found some
things with my Palm Vx OS v3.5 :

	1 - In "Options/Global preferences" when you set "Open all databases
in read/write" you must get out and back in DB to see the change.

	2 - When displaying the scroll up/down buttons stay in reverse
after the first tap until the top/bottom ends are reached.

	3 - In the "list view editor" the end of the phrase "Use this view
to edit record" is not shown. Part of the "d" is missing.

	4 - When selecting a record in the database linked by a "Link" type
field, the scroll buttons don't scroll continusly when you keep pressing
them. BTW the buttons stay in reverse video like in 2.

	5 - In the english version, some texts are in french :-) (example :
the title of the empty help screen about calculated field script).

	6 - Reseleting the calculatd field type in the "Database Design"
view resulted in a "MemoryMgr.c,Line 4359, free handle" error. The new
field didn't survive the reset. I reproduced the case.

	I'm going to bed, now :-)

	Fab.

[pilot-db-list] DB on Handera 330 (Re: beta or release)

[Hsueh-li Y. <y3...@po...>]

> Are the beta free of bug?
> Except the Global Find bug, i didn't receive reply about the last beta.
> To build the release we(Scott and me) need more return, please help us.
> Salut,
> Marc.

Salut, Marc,

First I should say that I really appriciate your developement on Pilot-DB.
When I first get my Handera, I've tried all major database applications on
Palm,
and I think DB is simply the best, even on the versions without Handera
support.

However there're still many display issues on Handera.  Should I report them
one by one?  For example, the icons are too small.  And on the system
"prefs-applications" window, the other applications which support high
resolution
shows "High-Res", while DB shows "Scale To Fit".  And many other problems
when rotating the screen or using small fonts.

I know that Handera is a rather strange model and it's quite normal if you
put
other works in priority.

Bon courage,

YEN

Re: [pilot-db-list] record display/layout hints

[<pef...@fe...>]

On Mon, 5 Nov 2001, Fab wrote:

> > field "Foo" label
> > field "Foo Number" integer "Number"
> > field "Foo Size"   integer "Size"
>
> 	which would be described by :
>
> field <Field_Name> <Field_Type> <Field_Label>

Yes, I do agree that this would be preferable (and make the code much
cleaner!).  However, it requires changes to the layout of the DB file,
specificially CHUNK_FIELD_NAMES.  I wanted to avoid this since it
requires
 - having incompatibilities between various versions of DB
 - hacking db-tools to produce the new format
 - hacking other UI components of pilot-db to allow editing of the label
   field.

-Peff

[pilot-db-list] New Text on the Web-Site

[<aji...@t-...>]

Hi,

I've just updated the text on the main page of 
our web-site. Please check for spelling mistakes,
and let me know what you think.

I hope the new bug-free version will be available at

http://sourceforge.net/project/showfiles.php?group_id=621

http://sourceforge.net/projects/pilot-db/

As soon as possible (ASAP)

Hans

[pilot-db-list] beta or release

[Chalain Marc<mar...@vo...>]

Are the beta free of bug?
Except the Global Find bug, i didn't receive reply about the last beta.
To build the release we(Scott and me) need more return, please help us.
Salut,
Marc.
____________________________________________________________
Faites un voeu et puis Voila ! www.voila.fr 
Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. 

[pilot-db-list] bug on Global Find

[Chalain Marc<mar...@vo...>]

I corrected the bug on the Global Find. You will have in the next beta.
Salut,
Marc.

____________________________________________________________
Faites un voeu et puis Voila ! www.voila.fr 
Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. 

Re:[pilot-db-list] Global find crashes

[Chalain Marc<mar...@vo...>]

> If I use the palm find, my palm crashes.  If I use a hack to exclude 
> searching DB then it does not crash.  Any ideas? Is this a known problem?  I 
> currently only have one database in DB which I created with the latest beta 
> of db 0.3.3

Interesting, i thought to correct the global find.
First you can disable the global find for all databases in the Global Preferences box and for one database in the database preference.
Can you send me your database? or which types do you use?
The pilot-DB vesion is the latest? i uploaded it sunday afternoon. The previous crashed on the global find.
Salut,
Marc.
PS: Which PalmOS version do you have?
____________________________________________________________
Faites un voeu et puis Voila ! www.voila.fr 
Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. 

Re:[pilot-db-list] Global find crashes

[Chalain Marc<mar...@vo...>]

There is a bug on the global find but i didn't see it on the emulator, it's only on the devices. It will be hard to correct it in this circonstences.
Salut,
Marc.


____________________________________________________________
Faites un voeu et puis Voila ! www.voila.fr 
Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. 

Re:[pilot-db-list] Filters in cvs info file

[Chalain Marc<mar...@vo...>]

The filter support on Pilot-DB are not still freeze. I don't know haow i will complete it.

Salut,
Marc.
____________________________________________________________
Faites un voeu et puis Voila ! www.voila.fr 
Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. 

[pilot-db-list] Global find crashes

[Anthony S. <asc...@ho...>]

If I use the palm find, my palm crashes.  If I use a hack to exclude 
searching DB then it does not crash.  Any ideas? Is this a known problem?  I 
currently only have one database in DB which I created with the latest beta 
of db 0.3.3

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: [pilot-db-list] Re: calculated field

[Fab <kr...@bi...>]

> > Relational Detabase systems usually don't have such a feature
> > (and I think I know why). The data is not regarded as sorted
> > in any useful way until it's queried with a specific sort
> > order.
> 	I agree.  The way I see inter-record calculations working is
> exactly like this.  First records are sorted, then the script is run.
> When these scripts are rerun is a big question we should think about.

	IMHO, it's a problem that can be solved in distinguishing the
database fields from the "presentation" fields. Calculated fields should
be calculated only with fields from the same record. Inter-records
calculations like agregates should be calculated each time they are
displayed on a view. Doing so, you can maintain the relational point
of vue. Ok, you migt say, but calculations will take a long time. That's
true, but I can't find another way to solve the dilemna.
	BTW, such a way could lead to imagine "presentation only" fields,
with results not stored in the database, wich would be very cool for the
database volume. For exemple, if you have to display the sum of two
fields, why always store the result ? Or we could display some values
in alternate units without storing the same values.

	Fab.

Re: [pilot-db-list] record display/layout hints

[Fab <kr...@bi...>]

>  - implement a field type of "null" or "label" which did not actually
>    have a data item in each record, but would be displayed in the record
>    table using only its name.

	I agree with this one.
	But I think that creating a special label for displaying each
field would be simplier than a special syntax. So instead of :

> field "Foo" label
> field "[Foo] Number" integer
> field "[Foo] Size"   integer

	we could have :

> field "Foo" label
> field "Foo Number" integer "Number"
> field "Foo Size"   integer "Size"

	which would be described by :

field <Field_Name> <Field_Type> <Field_Label>


	Fab.

Re: [pilot-db-list] record display/layout hints

[Scott W. <swa...@my...>]

Now I get it. ;)

	HanDBase solves this problem with a label field type that doesn't
store any data, it just spilts the records into sections visually.  I
think you suggested this earlier.

	Your earlier ideas are making a lot more sense now ;)  I would
probably make a specialized form and use it as a plugin to view your data.
Like you said earlier, you could imagine a little script that would layout
the form for you given the field names and their relation ships...

	-Scott

Re: [pilot-db-list] Filters in cvs info file

[Tom D. <td...@us...>]

On Monday 05 November 2001 03:12 pm, Nicholas Piper wrote:

> I presume the filter information is stored in the PDB, so pdb2csv has
> access to it. Is anyone working on permitting the filters to be saved
> into the "info" file ?

I have only added float support to the latest devel copy of pdb2csv/csv2pdb. 
I still need to add the remaining new field types first. Sorry.

Re: [pilot-db-list] record display/layout hints

[<pef...@fe...>]

On Mon, 5 Nov 2001, Scott Wallace wrote:

> If you do this, then essentially you have 2 completely distinct record
> structures, one for the "Foo" class and one for the "Bar" class.  This

Yes, exactly.

> means that each record is big enough to hold data for both classes, but
> only a small subset of these fields are actually used.  This would
> be more of a problem as the number of classes gets bigger.

But for my purposes, it's possible (and in fact, likely) that both Foo
and Bar will be filled in for a given record. Perhaps I should describe
my intended application. :)  I'm trying to replace paper forms that an
agent in the field will fill out with a database on a Palm. Currently
the agent fills out the paper form, drives it back to the office, and
transcribes it by hand into a PC. The idea is to hotsync it rather than
transcribing by hand, and to have records of previous forms without
carrying around a box of paper.

So, with that in mind, each field in the paper form is unique and may be
filled out along with any other field. That is, there may be "Foo"
components and "Bar" components for a single form, each with its own
distinct set of attributes. I don't necessarily care that the attributes
are named the same thing; however, I have to deal with the fact that
sometimes they are, which would create ambiguities in the field names.
If it just says "Attrib3," then which one is it? So you want to use an
unambiguous name, like "Foo Attrib3". However, this makes the UI klunky
since your screen space is very limited. You can't use the concept of
visual context to know that Attrib3 belongs to Foo (because it's right
under the Foo heading, say). That's the problem that I want to solve.

> Why wouldn't you make 2 databases?  This would really cut down on the
> wasted space. One db would define the "Foo" class and another
> the "Bar" class.  Then you could figure out some way to view them
> together....?

I considered that, but discarded it as too complex. I could have a "Foo"
database where each row in the database corresponded to a row in the
"main" database. Keeping those in sync seems like it would be a lot of
trouble.

-Peff

Re: [pilot-db-list] record display/layout hints

[Scott W. <swa...@my...>]

If you do this, then essentially you have 2 completely distinct record
structures, one for the "Foo" class and one for the "Bar" class.  This
means that each record is big enough to hold data for both classes, but
only a small subset of these fields are actually used.  This would
be more of a problem as the number of classes gets bigger.

Why wouldn't you make 2 databases?  This would really cut down on the
wasted space. One db would define the "Foo" class and another
the "Bar" class.  Then you could figure out some way to view them
together....?




>
> > In this case, it sounds like your original idea will probably be best.  I
> > can't think of another elegant way to do this.  But what if you called
> > attribute 1 "[Foo] Attrib1" and attribute 4 "[Bar] Attrib4" would
> > attribute 3 be "[Foo,Bar] Attrib3" ?   It seems like this might get out of
> > hand if there were 5-10 or so classes.
>
> No. Each individual field must be uniquely named, so "[Foo,Bar] Attrib3"
> wouldn't work. You would have two fields, "[Foo] Attrib3" and "[Bar]
> Attrib3".  Otherwise, how would you sort out the fact that they may have
> two different unrelated values? It's just that the names of the fields
> happen to be the same.
>
> -Peff
>

-- 

Re: [pilot-db-list] record display/layout hints

[<pef...@fe...>]

On Mon, 5 Nov 2001, Scott Wallace wrote:

> In this case, it sounds like your original idea will probably be best.  I
> can't think of another elegant way to do this.  But what if you called
> attribute 1 "[Foo] Attrib1" and attribute 4 "[Bar] Attrib4" would
> attribute 3 be "[Foo,Bar] Attrib3" ?   It seems like this might get out of
> hand if there were 5-10 or so classes.

No. Each individual field must be uniquely named, so "[Foo,Bar] Attrib3"
wouldn't work. You would have two fields, "[Foo] Attrib3" and "[Bar]
Attrib3".  Otherwise, how would you sort out the fact that they may have
two different unrelated values? It's just that the names of the fields
happen to be the same.

-Peff

[pilot-db-list] Filters in cvs info file

[Nicholas P. <ni...@ni...>]

I presume the filter information is stored in the PDB, so pdb2csv has
access to it. Is anyone working on permitting the filters to be saved
into the "info" file ?

This would allow me to replace the .csv file with new data, merge it
with the .info file to make a new .pdb and keep my current filter
settings.

Cheers,

 Nick

-- 
Part 3 MEng Cybernetics; Reading, UK       http://www.nickpiper.co.uk/
Change PGP actions of mailer or fetch key see website   1024D/3ED8B27F
Choose life. Be Vegan :-) Please reduce needless cruelty + suffering !

Re: [pilot-db-list] record display/layout hints

[Scott W. <swa...@my...>]

On Mon, 5 Nov 2001 pef...@fe... wrote:
>
> This is a cool idea, too, but is not exactly what I'm talking about (at
> least I don't think so).  In your example you represented rows of a
> table with four fields (name, number, size, quality), whereas I don't
> necessarily have the same attributes for "Foo" as I have for "Bar".  To
> change my example form, I might have:
>
> Foo
>   Attrib1 ___
>   Attrib2 ___
>   Attrib3 ___
>
> Bar
>   Attrib3 __
>   Attrib4 __
>
> It's ok not to display them as a table; I'm just trying to avoid having
> to call them "Bar Attrib3" in the UI.


In this case, it sounds like your original idea will probably be best.  I
can't think of another elegant way to do this.  But what if you called
attribute 1 "[Foo] Attrib1" and attribute 4 "[Bar] Attrib4" would
attribute 3 be "[Foo,Bar] Attrib3" ?   It seems like this might get out of
hand if there were 5-10 or so classes.

Re: [pilot-db-list] record display/layout hints

[<pef...@fe...>]

On Mon, 5 Nov 2001, Scott Wallace wrote:

> 	The advantage of this approach is that it doesn't require
> thinking about how the data will be displayed when you decide what should
> be in each record.

This is a cool idea, too, but is not exactly what I'm talking about (at
least I don't think so).  In your example you represented rows of a
table with four fields (name, number, size, quality), whereas I don't
necessarily have the same attributes for "Foo" as I have for "Bar".  To
change my example form, I might have:

Foo
  Attrib1 ___
  Attrib2 ___
  Attrib3 ___

Bar
  Attrib3 __
  Attrib4 __

It's ok not to display them as a table; I'm just trying to avoid having
to call them "Bar Attrib3" in the UI.

> 	There is an experimental plugin interface in db, that I have been
> looking at a bit lately.  It seems like it supports plugins for new list
> views.  I think this would be a great plugin capability, I would
> definately use it.

I haven't looked too heavily into this, but if it's possible to use it
and not disturb the main code, all the better.

-Peff

Re:[pilot-db-list] record display/layout hints

[<pef...@fe...>]

On Mon, 5 Nov 2001, Chalain Marc wrote:

> Do you read this mailing-list? Do you use the snapshot version?

Admittedly I just joined the list...I searched for relevant threads but
couldn't find any. Sorry if this has been discussed before. I'm happy to
receive pointers to threads that answer my question.

> You can create differents views in th ListView for a long time. You
> can display only few fields in the table and change the view with the
> right top list box.  Now with the snapshot version when you edit a
> View you can check a bow to "use this view to edit a record". Like
> that when you select a record in a view, DB display only the view
> fields of this record and you have a button on the rigth top to
> display all fields.

I have checked this out in the snapshot, but it doesn't do exactly what
I want. My problem is not wanting to edit specific views of a record,
but rather to allow the user to enter entirely new records that have a
large number of fields. The large number of fields can be cumbersome,
but having contextual layout (using headings rather than giving
unambiguous names for each field element) can save a lot of screen real
estate.

-Peff