While enhancing a routine to verify LH files I came across three items on the report that I can not resolve. They are three files that are in the SYSPROG.DBT and they do not exist. I can not seem to use the DATABASE MANAGER to resolve this problem.

The SYSTABLES record for DICT.MD looks like this…

F1=RTP57*REVBOOT

F2=DICT.MD

F3=GLOBAL

F4=DICT.MFS|RTP57

Can someone help me resolve this.

I seem to recall running across this problem when CTO/ARev32 during one of the v8.x betas. As I recall if the file descriptor/pointer existed in the SYSTABLES file the upgrade process would generate and error and not actually install the LK and OV files at the OS level.

As I recall you can either delete the descriptor from the DBT and reapply the upgrades or do a clean install of OI and copy the LK/OV files to the REVBOOT folder.

You may find the errors for this in the install/upgrade logs.

How do you delete the descriptor from the DBT? I think I would like to do that rather than doing a clean install.

I have this problem will all installs mine and customers.

Are the LK/OV physically missing or just not attached? Are there entries in the Database Manager file list and do they show up in LISTMEDIA from TCL? Detaching and Reattaching them in DBM and updating the DBT might solve the problem if the REVxxxx files are there.

If not the DBT file can be edited from ARev or sometimes you can just use a simple text editor. Make backup copies first.

If you have several installations to repair it might be easier to do a clean install onto a local harddrive and make copies of the REVxxxxx files for the MD and DICT.MD and copying those to your various installations - so long as the REVxxxx jibe with what's in the REVMEDIA pointers.

Thanks Warren,

After using NETDRV.exe to change to "Universal Driver ver. 3.0.0.3" I can now open these files.

What I would like to do is to delete them. I do not want these files because they are not used in my application and I do not want to use the Universal Driver at this time.

With your information, I think I can edit the DBT and remove them from the DBT.

There is a white paper in the Works Downloads about the DBT file.

The files are so small why bother removing them?

You'll need them if you ever need to use the U2 connection, CTO or ARev32.

If you don't normally use the UD drivers, switch back to network driver you were using. Then create a temporary file. Switch back to the UD driver, copy the dict and data of MD into your temporary file. Shut down OI and the service if any and copy the REVxxxx files of the temporary files over the REVxxxx files for the MD. The frame headers in the temporary files should remain as pre-UD and should be accessible with pre-UD drivers.

I think DICT.AVERY_LABELS is also on the new LH format.

Instead of deleting, I'd convert them back to the old LH format and let the system tables ship as required. Our RevertLH program doesn't seem to be available for direct download, but a copy can be provided by sending an email to the usual addresses.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

Richard,

What version of OpenInsight are you running? The Universal Driver is the supported network driver. The All Networks 2.1 is old and not recommended for use.

Sean

This post specifically addresses the suggestion to detach and re-attach tables in the database manager to solve DBT issues. Depending on the circumstances this process may work.

The most thorough and recommended procedure is to build the DBT from scratch. Use a clean copy of the SYSPROG.DBT file and replace your applications SYSPROG.DBT. You shouldn't have any custom tables attached in SYSPROG.DBT so replacing it with a fresh version is OK.

The last step is to take the fresh SYSPROG.DBT file and your application's DBT file with a copy of the SYSPROG.DBT file. Afterwards you should login and re-attach any custom tables using the database manager.

This would guarantee there aren't any stale attach references affecting your application.

I'm in the process of replacing my old database server with a new one that has a different server name. I edited our main application's DBT file with notepad and replaced the old server name with the new server name in all occurrences. This solution worked great.

We wanted to use a brand new server name for the new server because our experience is that renaming servers in a Windows domain is never as easy as it sounds.

FYI, we are migrating from Windows Server 2003 SE with UD 4.5 to Windows 2008 EE R2 x64 with UD 4.7. Here is what we did to set up the new test server:

1) Install W2K8 server on new hardware and configure as an application server.

2) Restore the application and data files to the new server.

3) Install UD 4.7 for server and workstation. We did a new install since UD 4.5 was not installed.

4) Modify any REVPARAM files to point to the IP address of the new server.

5) Modify the application's DBT file to point to the new server name.

6) Modify any custom code that may reference the old server name during logon.

So far so good. I also checked the SYSPROG.DBT file and it had no server name references in it.

View this thread on the Works forum...