Can we split a Populated Class out of a FIle

[ConvertFromOldNGs]

by David Wilkinson >> Wed, 1 Jun 2005 2:32:09 GMT

We have been running Jade for some years now and some of our files are getting quite large. The largest jade dat file is 5.5GB and has multiple classes mapped to it. Is there any way we can extract one or some of these classes and move them to a different or new file?

The object is to get smaller overall file sizes thus shortening reorg requirements as new changes and modifications are done. It seems a n unnecessary overhead to have files this large.

[ConvertFromOldNGs]

by allistar >> Wed, 1 Jun 2005 3:27:35 GMT

Yes, you can remap classes between database files. The basic flow is something like this:

- make sure the new map file exists in the system. Typically this means loading in a .scm file that has that map file.
- make a file calls _params.txt and put it in the system directory. This should contain:

SchemaName ClassName newMapFilename
etc...

- run this process:

jadloadb path=<path> executeSchema=RootSchema executeClass=Schema executeMethod=_moveObjects noaudit=true ini=<ini file>

Note that if this process fails your database is essentially stuffed (because of the "noaudit=true".

This is how it was done in a JADE 5 system, I am unseure as to whether this still applies for JADE 6.

Hope this helps,
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

[ConvertFromOldNGs]

by Dave Mellow >> Thu, 2 Jun 2005 21:18:02 GMT

Thanks for the help Allistar, and we seem to be on the right track BUT...

At first I kept getting the following output... -----------------------------------
Unhandled SystemException on 2005/06/02 23:22:39
Computer= DAVEM001, Application= JadeLoader, Schema= RootSchema
SystemException: 1010 (not continuable, resumable)
* The requested method is not defined for the Type of the receiver
Error item: _changeAccessMode
Error object: 37.1

Call Stack History:
*** Current action and database transaction ABORTED *** --------------------------------------

.... so after some experimenting I found that altering "noaudit=true" to "noaudit=false" it seems to run OK including an Interpreter window popping up saying something like "updating class maps" and "class maps updated". But the result is that nothing has changed.

So with some experimenting I've found that I get the same result irrespective of what I put in the _params.txt file. I can essentially put any garbage in there with no errors reported.

So two things...
(1) Is there actually any point trying to run it with "noaudit=false"
(2) Have I interpreted the contents of the _params.txt file correctly. Given a Schema named "WTAJadeCommon" in which a class "RGNira" is defined which I wish to remap to "RG2" (currently RG), the contents of the file is a line...
WTAJadeCommon RGNira RG2

Does that seem correct? Many thanks for any help I can be offered.

[ConvertFromOldNGs]

by allistar >> Thu, 2 Jun 2005 22:13:57 GMT

Thanks for the help Allistar, and we seem to be on the right track BUT...

At first I kept getting the following output... -----------------------------------
Unhandled SystemException on 2005/06/02 23:22:39
Computer= DAVEM001, Application= JadeLoader, Schema= RootSchema SystemException: 1010 (not continuable, resumable)
* The requested method is not defined for the Type of the receiver
Error item: _changeAccessMode
Error object: 37.1

Call Stack History:
*** Current action and database transaction ABORTED *** --------------------------------------

... so after some experimenting I found that altering "noaudit=true" to "noaudit=false" it seems to run OK including an Interpreter window popping up saying something like "updating class maps" and "class maps updated". But the result is that nothing has changed.

So with some experimenting I've found that I get the same result irrespective of what I put in the _params.txt file. I can essentially put any garbage in there with no errors reported.

So two things...
(1) Is there actually any point trying to run it with "noaudit=false"

From what I understand this is purely for performance reasons. The remapping is a fairly intensive process, and disabling auditing removes a lot of the overhead.

(2) Have I interpreted the contents of the _params.txt file correctly. Given a Schema named "WTAJadeCommon" in which a class "RGNira" is defined which I wish to remap to "RG2" (currently RG), the contents of the file is a line...
WTAJadeCommon RGNira RG2

Does that seem correct? Many thanks for any help I can be offered.

Yes, that's correct.

Keep in mind that my description of this process applied to a 5.2.08 system - I have had no need to try this on a 6.0.? JADE system.

It may pay to ask Jade support if this process is changed, and if not then why are you not seeing the expected results. Sorry I can't help more.

Regards,
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

[ConvertFromOldNGs]

by Patwos >> Fri, 3 Jun 2005 3:34:21 GMT

I had a quick look at the _params.txt file that I used when splitting up one of my systems, also on 5.2.08 as per Allistar, and in my file the separators between the fields were commas not spaces.

Does it work if you change your _params.txt file to use commas instead of spaces as the separators?

eg: WTAJadeCommon,RGNira,RG2

Hope that helps,
Pat.

[ConvertFromOldNGs]

by allistar >> Fri, 3 Jun 2005 10:09:05 GMT

Hi Pat,
Yes, you are right. Sorry for leaving out that detail Dave.

Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------