I have tried to include the Swap_Database routine in my multiple data volume application manager. The basic idea is, that each volume has a separate OS file VOLUMEname.DBT. To switch volumes, I overwrite the APPLICATION.DBT OS file with the desired target VOLUMEname.DBT file, then call Swap_Database( Application ).

As I understand it, this *should* replace @TABLES and @VOLUMES entries to match the DBT file, but it does not. Is this Swap_Database problem a documentation issue (there is none), a usage issue, or should the routine just be removed from the system as unnecessary?

My guess is that the code goes something like

pre.code {

 background-color: #E5E5E5;

 border: 1px solid #000000;

 width: 450px;

 padding: 5px;

 font-family: courier, verdana, arial, serif;

 margin: 0px 10px auto;

}

  if (newDB=@DBID ) then
     // I'm already the current DB
     // Why waste time redefining myself?
     // But, what is self?  Can I know who I 
     // am when I am variable?
  end else
     // We are moving to a new DB
     ....
  end

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Your suggestion about Swap_Database seems likely, but it cannot be tested becuase @DBID is a read-only system variable. I can just attach the tables correctly and rebuild the .DBT file, but then what is the point of the .DBT at all? Sad, because swapping attach images *worked* in AREV.

Have you actually tried calling SWAP_DATABASE with a different database name?

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Sprezz,

I have been swapping the OS .DBT files and calling "Swap_Database( Application )" because Swap_Database seems to work only with the current application name. Calling "Swap_Database( VolumeName )" causes OI to expire with "SYS1009 - Invalid user login name."

You suggest that Swap_Database is programmed to do nothing if the application name provided is the same as the current application. This makes Swap_Database useful only when changing from one application to another, not for attaching different data sets within the current application, as Attach_Image did in AREV. Having to go through the whole attach process to swap data sets makes the .DBT concept seem rather pointless.

Gerald,

You suggest that Swap_Database is programmed to do nothing if the application name provided is the same as the current application. This makes Swap_Database useful only when changing from one application to another, not for attaching different data sets within the current application, as Attach_Image did in AREV. Having to go through the whole attach process to swap data sets makes the .DBT concept seem rather pointless.

The Sprezzatura Group is correct and yes Swap_Database is useful only when changing from one application to another, which is why it is not documented. I am not aware of anything in place to accomplish what you are attempting. The .DBT concept saves time in having to write routines for data that will always remain attached.

Sean

Revelation Software

Perhaps there is not a user name associated with the database you are swapping to.

Just because an account and a database have the same name, does not mean they are the same thing.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Hi Gerald,

I skimmed through SWAP_DATABASE. It looks like the program is misnamed. It contains logic for LOGTO as well as USE_ATTACH_IMAGE. For instance SWAP_DATABASE assumes that there is an application for the dbID you are swapping to, and that the current user is a user in that database too.

You could try having an application named MILLIWAYS, have it have all the users as you current application, then SWAP_DATABASE(MILLIWAYS), SWAP_DATABASE(MYAPP). I don't think you will be pleased with the result though, as the LOGTO parts of the program will reinitialise you environment.

It looks like the original design go lost.

BTW, I'm thinking we could move the DBT files into SYSENV records.

With 64K limit gone, there is no physical reason not to store the DBT as a repository item.

I'm sure there would be some tradeoffs. Any thoughts?

Bob

Bob & Sprezz,

Thanks very much for all the comments. My application has its own dataset and privileged access security scheme, and a single program and user interface window controls user-logon/data-access/security. Consequently, I need a way to swap .DBTs without reinitializing the user login, as Bob comments, so that the program MDI frame is untouched.

Sprezz remarks that users are defined by database, but my copy of OI lists users under the Application properties. My understanding is that OI does not distinguish between applications and databases, so that @APPID and @DBID are the same.

I think this is where all the confusion comes in. Users and environment settings should track the application login. By default, @APPID and @DBID should be the same. However, the developer should be able to save named database configurations (currently the .DBT OSfiles) and switch databases without affecting the login environment. Using @DBID to track the database instead of the application would allow a smooth transition to OI handling databases within applications.

Gerald

However, the developer should be able to save named database configurations (currently the .DBT OSfiles) and switch databases without affecting the login environment.

I agree.

Set_database MYAPP_DEV, MYAPP_TEST, or MYAPP_PROD come to mind.

Don't have it today though.

If we redo .dbt subsystem we'll try to put it in.

- Bob

I wrote a similar utility that just detaches and reattches. The startup routine for my app does the attaches for the production database. I ignore the dbt file… all it does is give a very basic set of tables to the application. Am I missing something here?

John

The DBT file might be slightly faster – but also has downsides (such as needing to be updated if the app is updated later for a new file … just as the AREV images did). I keep minimal files in the app's DBT (basically a single global volume that holds the security info needed to log in properly).

I do the same as you (using pretty much the same code as always used in AREV, just with the new function names). Adding volume sets just means adding a pointer or two of where they are located and no DBT's to mess with.

I'm a big fan of keeping things out of the dbt. Volume Pointers RULE!

Weirdly (and this used to SO confuse people on training courses) Users are associated with DATABASES not with applications and @Appid does not have to be @DBID.

The Sprezzatura Group

World leaders in all things RevSoft

Sprezz,

I recognize that from the user interface, one and only one database is associated with an application. On the other hand, a database can be associated with more than one application. This seems to be advantageous to those who prefer using programmatic attach commands as opposed to relying on the .DBT features of the database.

But since you make this distinction, can anyone illustrate the programming considerations which might necessitate using @DBID rather than @APPID? I would like to clean up my own code, of course.

Gerald

I'm not sure about putting the DBT into the repository. When converting a MFS from ARev I got into a situation where I couldn't get into the App. Editing/restoring the DBT saved my bacon.

View this thread on the Works forum...