6-years is a lot of time. During our first year we did small-VB apps for simple tasks and prototypes that we threw out.

We found one of the biggest tasks the effort required in VB to customize a form. You could go the "code-forever-and-800-line" method - then adding one more text box to the form takes two days to accomplish. Or, as we decided - we developed a "general maintenance" program - reads the "screen" object size/position/name from the database - so adding a new textbox to a screen is a DB change - not an app change. The name of the object self-binds to the STORED PROCEDURE recordset.

The whole reason I'm even telling you this, is that I appreciate the effort required to code in the VB world compared to the "non-object-based" and "non-event-based" world of the mainframe. This general maintenance VB client allows us to create a brand new application with basically no BASIC CODING. To us this is the ultimate in "reusability".

With all that said, our customers did not appreciate the R&D work the first two years - saw nothing from it - but we knew we were defining business rules and application concepts/conventions that would allow us to be successful for a long, long time.

Now, as far as numeric vs alpha reference codes. Having two-letter codes that the user puts in makes sense to me - for a table that has 10 items. Having an alpha-code for a customer name makes no sense to me at all.

In all our "reference code lookup textboxes" the user enters either the "reference code" (numeric or alpha - no fixed rule) OR the "description text". Pressing ENTER will either fill the field, or bring back a drop-down box with choices. So if a smart user knows to put code "1", they put code "1" and move along. If a novice user puts "SMI" then the drop down appears with all the "SMITH,xxx" names and they choose one and then move along.

We are all about "minimizing" keystrokes in our apps - since they are mostly clerk like - loading hundreds of health claims a day type stuff.

Personally, I believe that auto-number and other ACCESS-like concepts are for small-type systems. We like to have "obvious" keys on our tables where possible. For instance, I've seen a student-class system where the courses were represented with integer-keys. People know that 0011 is ENGLISH 11 and 4011 is MATH 11 and so on. So we store the course as a 4-character field. The system we replaced stored the course as an integer auto-number field. The key on our STUDENT/CLASS table is multi-fields - YEAR+BUILDING+COURSE+SECTION+TIMEVECTOR+STUDENTID. The other system had it as STUDENTID+CLASSID. Our concept allows for clustered tables that group data in the table in what we consider the the best method. Plus a user browsing through data with EXCEL, for instance, can actually make sense of it.