For practice, I wanted to try deploying and installing an application. The deployment worked as expected,

I logged into the application and typed the following into the system editor.

run rdkinstall "G:\MAIL_LIST"

The message back is:

G:\MAIL_LIST

FS110: Open table error. The handle "RTP57" is invalid for a volume directory.

The deployed files are in G:\MAIL_LIST

This is version 7.2.

Does anyone know what this means, and how to get around it?

David Kralman

David,

This is most likely because the copy of OI you deployed from was using the Universal Driver and the copy of OI you are installing to is using a driver other than the Universal Driver.

[email protected]

SRP Computer Solutions, Inc.

Thanks for the explanation Don, but I really don't understand what you said. What does the driver have to do with the output? I thought that a deployment was supposed to create files that would load into any OpenInsight regardless of what driver it was using.

I didn't want to create a runtime, just export an application, and re-import it. Since I'm just learning OI, I know enough to be dangerous, but not enough to get myself out of some of the messes I create, so since I had messed up so badly, I decided to start over, so I deployed the parts of the app I felt confident with, uninstalled OI, and reinstalled it. I might have chosen a different driver at that time. Is there a way to find out what driver I am using, and change it to something else without reinstalling OI?

David

If you run netdrv.exe without OInsight loaded it will tell you which driver is loaded AND allow you to change it. This can be done without changing your app though you will need to recreate the deployment.

The Sprezzatura Group

World leaders in all things RevSoft

Thanks Sprezzatura, I will try that, except since I deleted the OI the deployment was made from, I can't redeploy. I will try changing the current driver to the one I used when the deployment was created.

Had this been an update to an existing application for someone else, or maybe multiple installations, would I have to make separate deployments for every possible driver the others might be using?

Somehow that doesn't make sense.

David Kralman

David,

Had this been an update to an existing application for someone else, or maybe multiple installations, would I have to make separate deployments for every possible driver the others might be using? Somehow that doesn't make sense.

You don't have to go to that extreme. The Universal Driver creates tables that can only be seen and accessed by apps that also use the Universal Driver. If you create a table using an older client (like the All Networks Drive 2.1 for instance) then this can be seen and acessed by all clients…including the Universal Driver. So, if you know that you have to support multiple applications that might possibly be using different clients then your safest bet is to deploy using an older client. Reportedly there is supposed to be an upgrade in the future for the Universal Driver that will allow it to create backwards compatible tables. Until then…this is what you have to do.

[email protected]

SRP Computer Solutions, Inc.

I just spent a week dealing with UD3 file compatibility. I changed all my tables created under UD3 back to All Networks 2.1, so that anyone could access the tables regardless of the driver in use. Ugh.

If Revelation were to provide a utility which could rewrite UD3 tables in older formats, that would be very nice.

Gerald-

The UD 3.1 and UDH 3.1 bith have backward compatibility built into them. I'll look into getting a utility created for the 3.0 files that weren't backward compatible.

Mike Ruane

Wow. I expected no response, but you fooled me, Mike. Excellent.

I read every posting on the website

It would be really great to have the option of creating new tables in either format, as well as something like the Arev REMAKETABLE to re-create our existing tables in either direction.

Regarding our RDK upgrades, a checkbox for this in the deployment definition could make life easier.

If you develop on UD3 you can easily find yourself in a catch 22 situation. As you develop, new tables will be created in UD3 format. If you need to deploy to something non-UD3 you can set it back to All Networks 2.1 and make a deployment… but then you can no longer read from any of the tables you developed while using UD3… so you still cannot make the deployment.

(That is how it appears from the things I have tried, but maybe I am missing something.)

Having a file format with the limitations removed is important and will become more and more so, but it does cause a few problems sometimes. Being able to choose and having a REMAKETABLE for our past sins would really be a big help with eliminating the problems.

Thanks!

Noted, and already under review.

View this thread on the Works forum...