>>>>It's an idea worth some time. I don't think anything is going to make this a less onerous task though. I have to manually create all the indices, and the way they've set it up, in far too many cases, the tags themselves are going to look like Str(IntegerField1) + Str(IntegerField2) because uniqueness depends on more than one integer field - that is, unless you know an easier way of compounding integer fields into an index tag.
>>>
>>>Not easier, but more efficient:
>>>
>>>Instead of
>>>
>>>

>>>str(IntField1) + str(IntField2) && 20 bytes
>>>

>>>
>>>use:
>>>
>>>

>>>bintoc(IntField1) + bintoc(IntField2) && 8 bytes
>>>

>>
>>But more typing. Carpal Tunnel, here I come.
>>
>>>
>>>> And then the foreign key indices will have to follow the same pattern. I'd like to get my hands on the person who came up with the SQL database design.
>>>
>>>Yeah, it looks like a real pain in the acronym. But - can't you add an integer key yourself? For the foreign keys, you will have to do a lookup in the table that contains the primary keys, but it may save you trouble in the long run.
>>
>>I thought about that, but in order to relate the various child tables back to the parent table in order to add the new primary key as a foreign key, I still have to match their foreign keys back to their own stupid primary keys. And it's not as if there is one child table per parent, nor even one grandchild to one child. With all the manual work I have to do on this, I doubt doing that will really save me much time, if any.
>
>Do that as part of a data conversion/import routine. Data modeling "purists" do designs like what you described. Too bad they haven't read this:

Oh, yes. Once I get this nonsense converted into our own system, the records will all have proper unique keys based on a system generated meaningless field.

Anyway, it's going faster than I thought. I wrote a tiny program of 1 form that shows the table name in a textbox, and the fields in a multi-select list box. I select the field(s), and my code creates an index called TableKey based on the proper form depending on the type of the field(s) selected. Now at least, I don't have to type BINTOC() or STR() or TTOC() etc over and over again.

I still have to select the fields, but that's not a big deal. Now the only hard part, when the name of the table comes up on the form, is finding the damned thing on their one page database relationship diagram. I had it blown up to poster size (they provided it on 14x17 paper, and it's a real headache to read), but it's still a matter of searching for it so I can see what the heck the primary key is supposed to be.

>
>http://en.wikipedia.org/wiki/Primary_key