Gerard, Yes we did it, of course we did and I was brought up on Cobol and Algol in the 70's so I understand where you are coming from very well. There were always ways in which to get around potential locking problems whatever you were using. In fact data records were locked in Cobol by placing an "*" in a particular column of the data record as record locking only came about in Cobol at a later date.
I was on the conversion team with ICL in the early 80's when DBASE II single user was ported onto ICL's IBM PC equivalent Multi User Concurrent CPM (MUCCPM) by Digital Research before Multi-user PC networks had even been developed. We ran on thin ethernet at 10Mbs (we used to know it as Serial I/O) using protocol developed by Singer Business Machines who I joined straight from University and we had to allow for multiple "virtual machines" to update a single user DBASE II table because customers expected multi screens to be able to update the tables. http://www.mail-archive.com/[email protected]/msg78221.html It wasn't supported but we did it nevertheless because we used our in depth knowledge of the hardware and software, so much the same as today. The good programmers will always find ways to circumvent the shortcomings of Languages and Systems by lateral thinking. A long time ago I learnt that there is no "right" or "wrong" way to write software, there are just "ways", some of which may be more efficient than others. The end result is though that the end user NEVER EVER sees the work that goes into a program and doesn't in fact need to. They see the end result and if it works ... then fine, job accomplished. 4GL, RDBMS etc, etc still haven't changed the underlying attributes of good programmers to innovate and think out of the box and that is what makes the good ones stand out in the crowd. For example, I hate with a vengeance the .Net framework, but I work with it on a day to day basis, cursing the fact that I could write the same code in VFP far quicker.... but that is life. SQL Server is somewhat the same, but I work within its structure and restrictions... as well as working WITH all the superior bits that MySQL and M$SQL provide. Presentation and Application layers along with Data Layers are things that most good programmers will have learnt about years before the terminology was standardised and turned into a Mantra for everyone. We just didn't give all the attributes formal names. Consequently, the advent of Multi-Tier applications and OOP thinking wasn't a quantum leap, at least for myself. Embrace new technology and thinking as it is formalised and introduced but never forget that innovation and logical thinking is normally the way to solve most difficult programming problems and that is mostly a natural ability to concentrate under pressure and think outside the box... to whatever degree you are able. As for low level languages, I've done my share of writing in Assembler and supporting O/S's at that level, but the problems and solutions are exactly the same, apart from the fact that the restrictions on HOW you can solve problems at assembler level are obviously less than with a 4GL ... but the timescales are HUGE! I wrote a multi user ops system in 8K ... yes 8K not 8Mb or 8Gb that happily supported up to 127 terminals and gave ISAM files on the server with multi user access at the same time so I do speak with some authority, but what good would imparting that knowledge to new programmers achieve?.... Precisely nothing, that's what. It is in the past but the techniques and experience remain with me forever. There is a good saying.. "Experience is the one thing that you only obtain immediately AFTER the very time that you need it most" and it can't be taught, no matter how good a teacher you are, In essence, use the tools you have got to the best of your ability with your own creativity to solve the problems that are thrown at you. O, and just as a final addition. Take a look at some of the open source code and frameworks that are being developed by the younger guys these days. Some of the concepts and implementation methods are truly wonderful and innovative from a programming point of view (Geeky smile). Wow, that turned into a right soap-box session... oops! ... or should I say procedural "OOPS" being old school! Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Gérard Lochon Sent: 05 September 2012 12:06 To: ProFox Email List Subject: Re: auto increment > 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. Yes indeed, that's the genetic lack of open systems, but i wanted to especially point that because in only one operation you can make a lot of desagrements in many tables ; multiples accesses to each dbf to modify them needs a longer time and maybe is easier to trace back. > 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. You know, my mind is always wondering when i see asks and further discussions about that problem ; because it is not new, and through dozens of years still the same old chats are remaining, as algorithmic solutions have been found long time ago. So, sometimes it becomes boring. So that, so what ? It looks like a psychotic fix about this point, but what about the multi-user update of a "normal" value, like a stock value ? That is the same game. In earlier 70's, when neither RDBS nor L4G existed, we had, using procedural languages (as COBOL) to respond to the same questions. And we did it. It is curious that this knowlegde basis can't be transmitted trough generations of valorous programmers ... > 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. IMO, the only really secure way is to fully understand the underlying mechanisms, and practise, practise ... MSSQL is not written in MSSQL language, nor MySql is written in MySql language. They are written in low-level language, the same ones that we used long ago. Presentation and application layers have obscured minds. 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.
