>>Hello Victor,
>>
>>this is very interesting for me. Could you please be more specific on "design your tables properly"? What do I have to do?
>
>Mostly it's an integer PK for each table, because it's required for updates. It may work with other types of PKs, but generally then you lose support, because that's what practically everyone uses, so when you run into a problem you find only examples which may not work for you. Also, you may think of porting your RI rules, if you have created them in the database - foreign keys, triggers etc.
>
>There's also a matter of minimizing the traffic - for big lookups you may perhaps create two views, one narrow with all records but very few columns, for searches, and another one with all columns but only one record, for editing and updates.
>
>Or you can completely skip the views and go directly for cursoradapter, which does all of that but more openly, and much more under your control, so you can do whatever you want on any of before* or after* events (qv in help for CA).
Lately I've been thawing to the idea of using GUIDs for PKs. Makes it easier to consolidate databases from multiple sites, or do consolidated reporting. Even if the customer originally swore up and down they would never need that ;)
Regards. Al
"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov
Neither a despot, nor a doormat, be
Every app wants to be a database app when it grows up