I'm having a problem when deploying from my development version to our runtime version of OI.

Normally when I create a new table and its associated forms, etc, I perform a deployment of "All Application Entities." Up to this Monday, this has allowed the runtime to attach any newly created tables.

Beginning on Monday, all entities are deployed correctly to the runtime version except any new tables are not attached to the runtime version.

I can manually attach the tables but I have not had to do this in the past. The table must be attached each time the runtime version is started so I have placed some temp code in the MDI form to perform this. Saving the environment does not appear to work in the runtime…Perhaps this is not allowed in the runtime version.

The tables are listed in the view list of the Repository View screen. I create all tables in the Datavol folder of the runtime version and this Datavol volume is also attached to my development version. My development version loads all tables properly but the runtime will not attach any new table automatically.

I'm running OI 8.0.7 and Universal Driver 4.5.0.0 on a Server 2003 machine with all Windows Updates applied.

I've restarted the LH service, rebuilt the system index, sync'd the database and sync'd all stored procedures.

The upgrade log found in the runtime revboot folder has repeated lines stating, "Failed in attempt to create directory: \\vailmain\data\vailapp\." I double checked all server folder access rights and nothing has changed. I don't understand why it would attempt to recreate the runtime application folder. I'm performing a Deployment Type of "Upgrade/Module" as I have always done.

Thanks for your help.

Charlie

Charlie,

For what its worth, I have always found deployment of new tables to a runtime has many gotchas. When the new table is deployed it is supposed to update the database image. You can of course manually attach the tables and save the database image yourself "run define_database yourdbname, 1"

Additionally, if you have not marked your deployment to require users to be logged out the table will not be copied. And, the process of packaging the RDK instructs the deployment to place the tables in .\DATA. If you look at SYSVolumes there isn't a "DATA" volume. If your new table has indexes and dictionary it further complicates maters.

To work around these issues and to provide a level of predictability I ended up writing a custom routine that creates the empty file and dict in the volume of my choosing. I place the directives

UPDATE ROWS

SYSOBJ/TEMP_CREATE_TABLE

EXECUTE PROCEDURES

TEMP_CREATE_TABLE

I include the dictionary items in the RDK. The Deployment copies in the custom code and runs it before copying the dictionary items in.

HTH,

John

Hi John,

I tried mannually attaching the table and saving the database image. Worked great. Don't know what happened with the deployment after all these years but your solution did the trick.

Thanks for your help!

Charlie

View this thread on the Works forum...