Thanks for responding Gary. You’re right about Dave. He didn’t use long file names.

I’m narrowing in a little. I think it has to do with Codemine creating an appreg01 cursor in another data session. Even when I close down the application and reopen it the appreg01 table in the database has the imported data and the Codemine created cursor doesn’t. It would be cool to know where the data is coming from.

When I first got started with Codemine I changes the name of the database. I suppose that could be part of the problem. I'm too far down the road now to change it back.

Right now I’m going through the Codemine Help file and the cmregkey.vcx to get a better feel for what’s happening. I’d appreciate any thoughts you might have that could shorten the process. Thanks again Gary.


>Its been a real long time since I looked at Codemine and, whilst I cannot see it, it may be that Dave used long field named in the Appreg01 table (it is associated with a .dbc). If you export to free tables, long field names would be truncated. Maybe this is worth looking at although as I said, I cannot see Dave Lehr ever using long field names. However, you never know :)
>
>>My backup process includes copying all of the tables that users can modify to free tables that are put in a ZIP file. When the data is imported back into the application tables are ZAPPED then filled with data from the free tables. The appreg01 table is included in this process.
>>
>>All of the shared key data is in the appreg01 table but when Shared Keys is opened from the Application Registry Editor there is no data under Shared Keys while all of the Local Keys data is displayed. The application appears to run fine but I can’t edit Shared Keys from the Application Registry Editor and the thought that other things might be affected is worrisome.
>>
>>Can you tell me what I’m doing wrong? Let me know if you need specific code segments. I’m using Codemine 7.5