[Lazarus] Embedded database for Lazarus/Linux

[waldo kitty]

On 6/17/2010 18:03, Henry Vermaak wrote:
> On 17 June 2010 22:22, waldo kitty<wkitty42 at windstream.net>  wrote:
>> On 6/17/2010 15:26, Henry Vermaak wrote:
>>> What happens if your structures change?
>>
>> since you've both the old and the new, you simply process the existing data
>> file with the old structures, convert it to vars in the new structures and
>> then save it to a new data file in the new format... conversion programs
>> like this are pretty bog simple but they can be tedious depending on the
>> number of vars you have to work with... one of the sets i work with has over
>> 200 settings and options ;)
>
> Exactly, what a joke.

how? it is the same thing that a database does when you update its structures...

> If you used a database you wouldn't have to do
> anything like this, just update the table definition.  No conversion
> apps (what will a user make of this), no extra code in your app for
> this.

what will the user think? who says they even have to know about it? i dare say 
that it is easily done during the start-up of the application ;)

>>> Can you do relations?
>>
>> sure! you just do the same thing as in a database... you have your key here
>> and it is linked in each related record over there... nothing more than a
>> while loop walking thru the other data file(s) looking for a particular link
>> key in each record... i was doing that before i had to become a dBase II/IV
>> coder ;)
>
> Haha, you are looping through every record of all your files?  This is
> getting hilarious.

you seem to forget that this is the same basic thing that a database server 
does... there's no way around it... someone/thing has to iterate thru all the 
records to locate the matches... sure, maybe this is done via an index file... 
same difference since both sql and pascal can use indexes ;)

ok, ok, ok... so i understand using databases... i've been using them for 
years... since before sql was ever thought of, actually ;) it is much like using 
a FOSSIL driver to support comms on multiple types of systems and OS'... just 
like a FOSSIL allows the coder to concentrate on the mechanics of the app they 
are working on instead of having to also delve into the comms stuff, using a 
database (and server of some sort) enables a coder to concentrate on the app and 
not worry about how to handle the storage and retrieval of data... simply make 
the call with the info stuffed into the call and go on about the rest of the app...

> You seem to be slightly confusing app settings and app data.  Storing
> app settings (like options) in a database is definitely overkill
> (imho), but storing app data in an embedded database is a very good
> idea.

i'm not confusing anything... i've been using databases since before i found 
dBase II ;) someone else made the comment about storing app settings in a 
database, FWIW... deity knows that i've seen such many times over the years... 
but hey! it works... they use a table (they were called 'databases' back then 
and you had several of them) called settings or some such and there ya go... new 
versions may carry new options in that table... as you say above, change the 
structures and off ya go... employees, inventory, shipping, receiving and 
transactions are distributed throughout other tables ;)