While reading through the conversion process (again) I noticed there is a LH copy function that resizes all files to improve performance.
Because I attach the files programmatically and each client has their own data set, I would like to perform a similar performance improvement function after the OI10 conversion possibly using the new Get_LH_Info_LHStats function.
Any advice would be grateful.
Chris
While reading through the conversion process (again) I noticed there is a LH copy function that resizes all files to improve performance.
Because I attach the files programmatically and each client has their own data set, I would like to perform a similar performance improvement function after the OI10 conversion possibly using the new Get_LH_Info_LHStats function.
Any advice would be grateful.
Chris
If you can get your "Management console" (From the consoles menu) working, it is in there.
Requires some 'setup' actions. :smile:
I have the console running but only system files attached. I suspect that if no files in the dbt file then the console does not access the data file.
Also, I cannot find where to manage the file resizing in the console.
Chris.
Hi Chris
Have you actually installed the UD 5.2 UD Manager? would then
In the console you would then see in menu on left System Information | Management Dashboard | Users | Filing System | etc.
I Filing System the first item is LH Management. On the right - after you select the app, enter password to access the attached Volumes, select a file. You will then se on the table line - far right a text "Resize"
Richard
Hi Richard,
Do I have to have the UD5.2 running on my laptop?
I have seen the "Resize" button but do NOT have any of the PBC files available for resizing. I do not use the DBT file for attaching as I have copies of many different client data.
How can I get the attach the PBC data in the Console. I have the PBC application running while opening the Console. I suspect the application does not communicate withthe console.
Not sure where to go next.
Chris
Hi Richard,
Do I have to have the UD5.2 running on my laptop?
I have seen the "Resize" button but do NOT have any of the PBC files available for resizing. I do not use the DBT file for attaching as I have copies of many different client data.
How can I get the attach the PBC data in the Console. I have the PBC application running while opening the Console. I suspect the application does not communicate withthe console.
Not sure where to go next.
Chris
Hi Richard,
Do I have to have the UD5.2 running on my laptop?
I have seen the "Resize" button but do NOT have any of the PBC files available for resizing. I do not use the DBT file for attaching as I have copies of many different client data.
How can I get the attach the PBC data in the Console. I have the PBC application running while opening the Console. I suspect the application does not communicate withthe console.
Not sure where to go next.
Chris
I assume you have attached the app files at this point.
You could also attach each client data files manually from the IDE (dont save) for each client clean-up you want to do.
Did you select your application in → System Information | Management Dashboard | Users | Filing System | LH Management
Just to explain the sequence of events:
Start the application MDI with /DV=0 as one of the shortcut switches
Logon to the application during the MDI create event, user name/password/optional alternate data set etc
Attach the required data
Start RTI_IDE from within the application
Start OICONSOLE from with RTI_IDE
only to find that the data attached in the application is NOT available in the OICONSOLE.
Chris
Just to explain the sequence of events:
Start the application MDI with /DV=0 as one of the shortcut switches
Logon to the application during the MDI create event, user name/password/optional alternate data set etc
Attach the required data
Start RTI_IDE from within the application
Start OICONSOLE from with RTI_IDE
only to find that the data attached in the application is NOT available in the OICONSOLE.
Chris
Chris,
The OICONSOLE uses a different engine than the one you launched OpenInsight with. Therefore, it will not be aware of any dynamically attached tables from that engine.
Chris,
The OICONSOLE uses a different engine than the one you launched OpenInsight with. Therefore, it will not be aware of any dynamically attached tables from that engine.
Having just said that, you might be able to configure the OICONSOLE to use the inprocess engine and then this might work as you hoped. However, I have not tried that so this is just speculation.
Just to explain the sequence of events:
Start the application MDI with /DV=0 as one of the shortcut switches
Logon to the application during the MDI create event, user name/password/optional alternate data set etc
Attach the required data
Start RTI_IDE from within the application
Start OICONSOLE from with RTI_IDE
only to find that the data attached in the application is NOT available in the OICONSOLE.
Chris
Chris,
The OICONSOLE uses a different engine than the one you launched OpenInsight with. Therefore, it will not be aware of any dynamically attached tables from that engine.
Which is why you need to select the application name for the files you want to see (in the LH Management)
Just to explain the sequence of events:
Start the application MDI with /DV=0 as one of the shortcut switches
Logon to the application during the MDI create event, user name/password/optional alternate data set etc
Attach the required data
Start RTI_IDE from within the application
Start OICONSOLE from with RTI_IDE
only to find that the data attached in the application is NOT available in the OICONSOLE.
Chris
Can you post the EXACT step you went through.
e.g. what exactley do you mean by 'Start OICONSOLE from with RTI_IDE '
Which is why you need to select the application name for the files you want to see (in the LH Management)
Barry - Perhaps I don't understand something, but how would this dynamically attach his tables? These tables are attached through his application logon/create process.
Which is why you need to select the application name for the files you want to see (in the LH Management)
Barry - Perhaps I don't understand something, but how would this dynamically attach his tables? These tables are attached through his application logon/create process.
To access the tables you are required to enter the application name of the tables that are attached, I assume they cant be 'seen' as the application id is OICONSOLE and the tables are attached under appid of (say) PBC.
Which is why you need to select the application name for the files you want to see (in the LH Management)
Barry - Perhaps I don't understand something, but how would this dynamically attach his tables? These tables are attached through his application logon/create process.
To access the tables you are required to enter the application name of the tables that are attached, I assume they cant be 'seen' as the application id is OICONSOLE and the tables are attached under appid of (say) PBC.
I understood the reference to "OICONSOLE" as a name to the tool, not to the AppID. Regardless, the point I think Chris is making is that his tables are attached at runtime. So even if he connects to PBC, those tables won't be attached for him. That is, of course, unless the Management Console engine is being shared by the OpenInsight GUI IDE.
Which is why you need to select the application name for the files you want to see (in the LH Management)
Barry - Perhaps I don't understand something, but how would this dynamically attach his tables? These tables are attached through his application logon/create process.
To access the tables you are required to enter the application name of the tables that are attached, I assume they cant be 'seen' as the application id is OICONSOLE and the tables are attached under appid of (say) PBC.
I understood the reference to "OICONSOLE" as a name to the tool, not to the AppID. Regardless, the point I think Chris is making is that his tables are attached at runtime. So even if he connects to PBC, those tables won't be attached for him. That is, of course, unless the Management Console engine is being shared by the OpenInsight GUI IDE.
OICONSOLE is the O4W appid.
If you do Open Application you should see it there.
When you open management console, you are asked for an application name and pawword, that is where you enter OICONSOLE as the application.
OICONSOLE is the O4W appid.
If you do Open Application you should see it there.
When you open management console, you are asked for an application name and pawword, that is where you enter OICONSOLE as the application.
I appreciate the explanation, but it is still unclear to me whether you are expecting dynamically attached tables to be visible in the Management Console this way. Have you seen this work for you?
OICONSOLE is the O4W appid.
If you do Open Application you should see it there.
When you open management console, you are asked for an application name and pawword, that is where you enter OICONSOLE as the application.
I appreciate the explanation, but it is still unclear to me whether you are expecting dynamically attached tables to be visible in the Management Console this way. Have you seen this work for you?
dynamically attached tablesSo sorry, I missed this as the issue (I skimped the interpretation of dynamic)
Don, you are spot on.
I will see if OICONSOLE can be configured to synchronize with current attached data.
Chris
Post removed by author
Wow, just what I like to see - spirited conversation and debate!
OK, here's what's going on - when you start up the Management Console, it uses the engine server to log in to OpenInsight (by default, it logs into SYSPROG using the OICONSOLE user, though this can be configured per app to log in to that app instead). Once logged in, there are options to manage other apps by specifying the app name and password.
The Management Console will use that information on the relevant subsequent screens to start up another oengine, log into the specified app, and "do stuff" - get a list of tables, or manage user information, for example. After it processes that specific request, it shuts down that extra oengine.
SO…
- The Management Console will only see attached tables, because it runs as a separate oengine;
- There is no easy way to make it "share" the currently-running OpenInsight's oengine (though I suppose you could use the "engine name" parameter to try to make that work);
- Using the "manage another application" functionality still won't help, because (again) it starts up a separate oengine;
- And even if there was an "attach a table dynamically" option on that screen, since the oengine starts up, runs, and terminates for each command, your dynamically attached table will be attached, and then detached as soon as the engine shuts down again.
At this time, I don't see any way you can resize (or do anything to) tables that are not attached via the dbt. A workaround solution would be to attach the tables via the dbt in OI, use the Management Console to resize them, then remove them from the dbt. Inconvenient, I know, but at least it should work. Alternatively, you could _TRY_ to use the "engine name" parameter in the connection string (defined in the eserver.cfg) to "share" your OpenInsight/desktop engine, but I don't know if this will actually work as a solution.
For the upcoming 10.1 release, we will discuss what (if anything) we can do to enhance the Management Console tools to make something like this possible.
Hope that helps clarify the situation,
- Bryan Shumsky
You could try calling the remake function directly. The underling routine is named RTI_REMAKETABLE
Subroutine RTI_RemakeTable(Tablenames, tableParams, DestTableName, progressCallback) /* ** Remake a table in place, or optionally in a new location. ** Will adjust the frame size bases on the average record size ** sets threshold low * * Notes: * Nobody can be using the table * Creates a new revxxx, copie rows from the old. modfies revmedia to point to the new. * Replaces the existing RevXXXXX files with new ones, the old are renamed as filename_bak_date_time.lk / .ov * ( the old ones will have sizelock set ) * * Processes the data, dict and ! files * * * Tablenames required - fm delimited array of * tableParams optional - framesize:@fm:threshold:@fm:avgsize:@fm:reccount. You can pass one or all of the params. Nulls are replaced by the default. Default framesize = nearest k >= actual avg size and <= 32k Default threshold = 25% Default avg size = actual avg size based on 10% sample Default reccount = actual reccount + 10% * DestTableName optional - dest_name*dest_loc*dest_acct*dest_overwrite_flag * progressCallback optional - name of a function to call with progress information * if progresscallback ne '' then * progressText = 'Copying ' : sourcecount : ' rows' * progressPercentage = Int((read_cnt / sourcecount) * 100 + .5) * continue = function(@progressCallback( progressText, progressPercentage)) * end * * * **************************************************************************/
Hi Bryan,
Even before I read this reply I had a crazy thought. It would be convenient if we could attach a custom DBT file instead of the only one associated with its corresponding account. Then, instead of defining the path to attach, attach the custom DBT file. I would then have a routine to create the custom DBT file. Maybe that could solve the problem.
BTW within my application I have a number of user options to attach various data.
I get the IT department to organise a OS copy of the data every night. This enables me to recover any data (records) that have been mistakenly deleted. Also have the facility to attach previous years data or a demo data set for new users.
Hope this justifies attaching the data programmatically.
Just an Idea.
Chris
FWIW, there is an internal function named RTI_LOAD_DATABASE which will load an alternative dbt.
function rti_load_database(databasename, bUseAppIdforDBid) /* ** databasename (in) = name of dbt file, without the suffix ** bUseAppIdforDBid (in) = flag, true to set @dbid = @appid<1>, false to set @dbid = databasename ** defaults to false. ** ** returns true on success, false on error **You can call that to load an additional dbt file. It behaves as an XOR of the dbts. The resulting set of attached tables contains the tables which were already attached + the list of tables in the new dbt. If the same name appears in both dbts, the newly attached replaces the earlier one. You probably want to pass true for the bUseAppidforDbID. OI may get confused if @bdId is different than @appid. The function is used internally when logging from one application to the next, hence the flag defaults to false.