On 6/17/2010 18:03, Henry Vermaak wrote:
On 17 June 2010 22:22, waldo kitty<[email protected]> 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 ;)
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
