I never thought of having a key that wasn't visable. But that is a good point. Then I don't have to worry about what happens if they change the client id. How would I go about generating this integer id, then? With the client ID, the user typed it in so all I had to worry about was making sure it didn't exist already. I'm not sure how to generate unique keys for all my tables.

Views seem to be the way to go. I think that was the unanimous answer.

I remember the text mentioning parameters in views. I'll have to look at that more thouroughly. As to navigation buttons, I can see why they would be useless in a large table, but they're not bad for some of the smaller tables.

I don't know anything about client-servers. We're able to just use the table in its entirety with no problems.

Your last paragraph is way over my head. I'm not very familiar with SQL. I know just enough to be dangerous. :)

Thanks,

-Michelle



>I would suggest, first of all, using a unique system key for all tables. This is a value that is never seen by the user but is manipulated by the system. An integer makes a great key because retrieval based on an integer key is very fast. Some people using a common naming scheme like nID or cID based on whether the key in numeric or character. Although your Client ID is a key you can make it a candidate key. If it is seen by the user, they may have reason to change it and if they do, your primary integer is still safe and unchanged.
>
>By using views, any table that has the client key as a foreign key (not the client id field!) can be joined back to the client name table so that you can display names and phone numbers quite easily.
>
>I would also suggest using parameterized views and avoiding navigation buttons. For instance, in your client table the parameter(s) might be first name, last name, phone number etc. and these parameters are used to find a client. You don't ever need to do next prev etc. When you want another client, you 'find' them by entering the parameters on a parameter screen.
>
>The parameters will retrieve one client at a time into your view.
>
>Why do this? In VFP even with 5,000 clients it is easy to skip next and previous. You basically open the dbf and go for it. But if your application is Client Server you don't want to download 5,000 records every time you open the client screen. So build your application in anticipation of C/S and think data sets. If you use views everywhere it can be very very simple to switch to SQL Server or Oracle with barely a change in your code. The big thing is only retrieving the data you require and not simplying opening a table and having all the data at your disposal. Using integer keys in a DBF are easy to change to Integer Identity keys is SQL Server.
>
>If all of your data handling goes through a class that does a save, etc. you can build in retrieval of the newly inserted primary key value either as a VFP stored procedure or an @@Identity SQL passthrough call to Sql Server.