Gerard, That is true for ALL the data not just the pointer table so that isn't an issue when DBF's are used because the whole of the DBF structure is available to change as long as the user has access rights. Normally a "$ Share is sufficient to hide the data away from potential prying eyes on server hosted hardware. In any case, ALL data is available for hacking if one has the relevant expertise.
My point in identifying this method was to indicate that there is a simple Multi-User alternative to using Autoincrement which is robust and reliable. The only really secure way of hiding your data is not to put it in DBF's in the first place but to put it into a SQL container like M$SQL or MySQL etc. Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Gérard Lochon Sent: 05 September 2012 07:09 To: ProFox Email List Subject: Re: auto increment > > My preferred method is a UDF() that interrogates a table holding one > record for each table in the system and it's next primary key. Access > the relevant record, lock it for a short period of time whilst > incrementing the next sequential record then unlock and return back > the PK. This works faultlessly in Multi user systems. > With such a method, you have to perform integrity control prior to use it. Because your DBFs are not in a safe. Any customer is able to open your nextpk table with excel and modify it ! Gérard. [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
