You can't blame the horse if the rider can't ride. There's many products running or almost running built by those that don't understand the basic structures of a data system. Doens't matter what the language is in this case. That one sounds so simple that you could convert it in a matter of minutes. Not sure how many user screens and reports would be required since I can't see it.

I'm an old Foxpro programmer and I always created keys based on a function to create a unique filename within Foxpro that uses date-time sequence to create a 10 digit word that you index on and create a function to create a new key based upon a small loop and test existence before creating it. You can also breakback the key to get the date time it was created. The key remains in the file with the data but can be used in tables below to quickly and acurately get to the record or a collection of records. I've always found that users can come up with the dardest things to screw up your keys when using user entered data as keys. MS bought Foxpro for it's optimizing engine for SQL querying called Rushmore even though they didn't want it. In fact, it became so popular it was cutting into their bottom line that they decided to kill it off before it went too far. Clipper was bought out by CA and killed by their ineptitude. Dbase, on it's last breath, by Borland who also was on its last breath. MS licensed Sybase SQL server for running on OS2 and quite literally stole its guts to build MS Server which ran on NT. I always felt as though Sybase really got ripped off in that one. Access was also created from this collaboration with Sybase and it was supposed to be a stand alone version but has always from it's beginning fell way short. But, that's not by accident because like Foxpro, they didn't want to relingish control and profit letting it get out of hand as Foxpro has done. With some 3rd party addins, Foxpro could do anything. It could do word processing, spreadsheets, email, etc. One company even used it to make a document storage system which was quite good. And, with a SQL backend, you could write thin clients and run a SQL system while at the same time utilizing Tables locally to do some of the heavy lifting. I wrote a settlement system for one of the major railroads that processed over a million records a day in SQL in 1992. It was MS server 2.0 at the time and I copied down 100 records to a local table at a time to do the processing and update to show they were processed. Could run it in tandem on as many PCs as desired although its optimum speed was on 4 pcs at a time. With just SQL or just local tables the chore would be very hard to have done. But, since you have the capabilities of both it's not hard at all. I've done barcoding, IDs System, cases tracking, time and attendance with Kronos clocks, and many more diverse things including reading barcodes and scanning. All wit

I too am at 26 yrs of it and have wondered a lot lately how the cobol programmers felt because our PC tech was new and different and they were so stuck with their tech. Now, I'm finding I'm like them where the tech is changing and I'm stuck with the existing. Another big change is that this new younger breed of ambitious people rising in the management ranks (not techie's either) believe they know tech or at least like to protray it and are willing to make decisions based upon their own limited and bias knowledge of tech. Their disdain for us techies seems to be a basic requirement for them because they don't want anyone knowing they don't know what they're talking about. Plus, they like to make all the decisions and not defer to the techies. Plus, they hate us when they see us get paid better than them and think that its an injustice to them. The world doesn't respect us anymore. They feel technically empowered (self sufficient) and don't depend upon us for knowledge and understanding of it. They're all iphone experts.