>I think the original newsgroup question was related to not wanting the user to even SEE the data so they would need to do something with encryption, go the COM route, wait for VFP7 or move to an SQL database.

Aside from the COM and encryption routes, their ain't a whole heck of a lot you can do. You can do it if you go to Oracle or other SQL DB, but you have to do all the connecting behind the scenes [i.e., in your code], using an ID and PASSWORD unknown to your users.

At that point you lose the ability for your triggers to populate the UPDATED_BY column with anything but the ID you logged in with. I guess you could get the actual user ID from the client OS or network server and populate that field yourself and make it updatable. What a PITA that is because with a trigger, I let Oracle figure out if the record is actually being updated or inserted. Now, I have to write code on the VFP end to see if any fields changed or a new record was inserted. Granted, this is not a whole lot of coding, but...

Also by connecting with a generic ID and password, you have to devise a scheme to determine if the actual user has select only, update, insert and/or delete privileges. Otherwise, you could just create a role for all the different access privileges and connect each user to the appropriate role.

There are other considerations as well, but as you can see, you are trading one allotment work effort for another. IMO, you are doing more work trying to limit the users to one and only one way to access the data. Also, IMO, this is very short-sighted design in the long run.

With the exceptions of CBI, national security, etc., I can't see many other good reasons to block alternate access to data they already have.