loading a _seqvals.d file with no header from a command line

[Sergio Giusti]

Hello

im new to progress db admin and im trying to load a dumped sequel current values (_seqvals.d) file from a command line without having to manually enter the database using the PPPDEV tool and load it.

upon trying

PROUTIL dbname -C load _seqvals.d

i get an error that the file cannot be loaded as it has no header.

Is there a way to load the file without a header? or another command i can use to load the file?

im trying to put this command into a script that will automatically load the file without user intervention.

thanks for any assistance you can offer

regards

Sergio Giusti

 

[RealHeavyDude]

The proutil -C load is only for loading binary dump files. The _seqvals.d is in ASCII format and cannot be loaded from the command line. Your best bet is the data administration tool, in the load data and definitions menu there is a menu item for loading the sequence current values.

Other than that, you could write your own ABL procedure that wraps the procedure that is called from the menu item.

Heavy Regards, RealHeavyDude.

 

[Sergio Giusti]

ok thanks, im snookered then as i was needing this done without the user (most of whom would have no idea how to enter the data administration tool and load the file) having to do anything.

thanks anyway.

 

[rzr]

you could still write a program to load the data file as RHD suggested and calll this progarm from your script.

 

[RealHeavyDude]

Dumping & Loading data is a database administrator task. Users of the application should never be bother with going into a database maintenance tool like the data administration. It is expected that, you as the designated database administrator, have the needed know how to use tools like the data administration or, either have the know how yourself on how to write such a wrapper procedure or somebody at your disposal that can do that for you.

Heavy Regards, RealHeavyDude.

 

[rzr]

there's KB# P122615.. that might interest you

 

[Sergio Giusti]

yeah i dont know how to do that, what im doing is writing a batch script that will convert a type i database into a type ii database by dumping out the data _user.d and _seqvals.d from the db, del it, create an empty type ii db from a backup file with the type ii df already in the db and then load in the _user.d and _seqvals.d files and then load in the data (.bd files).

I have managed to get it to do everything i need except load the _seqvals.d file.

thanks anyway, ill need to leave this to be a manual process and provide instruction on how to do that.

 

[rzr]

provide instructions ??? to whom ??? would'nt you be doing it as the dba

 

[Sergio Giusti]

no its for a group of customers, they will have IT staff but i doubt they are Progress DBA's, to that end, im not really a progress DBA, ive just been asked to work on getting this done.

 

[TomBascom]

As RZR pointed out -- it can be automated.

The gory details vary depending on Progress version but the kbase article referenced shows the "lowest common denominator" way to do it.

It may be self-serving of me but... your company might want to consider engaging someone who is a DBA and who has some familiarity with these sorts of issues to write a type 1 to type 2 conversion script.

 

[RealHeavyDude]

Storage area tuning is something that can only be done on live data plus over times it may change dramatically as users may use the application in different ways than you would event think of. To come up with a design that fits all your customers is simply a least common denominator administrative wise, not storage or performance wise. Therefore I have automated the dump & load process. The only manual step is using a tool I have developed to create a re-designed .df and .st file. Still the process must be executed from time to time because of the changes in the database. But it takes know how to do that, therefore I can only second Tom although I am not in the market right now

Heavy Regards, RealHeavyDude.

 

[aravabhumi_madhu]

yeah i dont know how to do that, what im doing is writing a batch script that will convert a type i database into a type ii database by dumping out the data _user.d and _seqvals.d from the db, del it, create an empty type ii db from a backup file with the type ii df already in the db and then load in the _user.d and _seqvals.d files and then load in the data (.bd files).

I have managed to get it to do everything i need except load the _seqvals.d file.

thanks anyway, ill need to leave this to be a manual process and provide instruction on how to do that.

May I know How did you load _User.d file?

 

[RealHeavyDude]

I rolled my own. As far as I found out there is no way to dump the _User table contents without having a development license installed. It has been this way ever since and customers did complain to Progress about that ever since too ...

At the danger of risking my job I am not allowed to post any code here ( risk management's gone rogue ... ) - therefore I can only explain it, but that one is rather simple: Just loop through the _User table ( with a for each for example ) and use the export statement to export it to a file. It's as simple as that ...

If you look at a .d file that has been created by the prodict utilities you will find some trailing information. You can just copy it into your file. The most important information in that trail is the code page and the number format. The ( prodict ) load basically don't cares if the number of records and bytes are missing or wrong.

Heavy Regards, RealHeavyDude.

 

[TomBascom]

If you are dumping and loading _user and sequences for just a few databases and only once in a while it isn't that big of a deal to just go into the dictionary and run through the menus. A bit of an annoyance, and it needs to be on your procedures checklist but it isn't the end of the world.

If you are putting together a process to be used frequently or on a lot of databases then, yes, you are going to want to take the time to automate it. In that event you really need to have a development license available so that you can build procedures as RHD has outlined. There is no generic way to automate these things without doing so.

(You can load .d files without *any* of the trailer info -- the code page and numeric format will default to whatever is in $DLC/startup.pf or whatever you put on the command line for those settings. That may, or may not, be an acceptable situation -- it depends on your data.)

 

[Stefan]

We used to use a .d load for some initial database contents - but the development license restriction was a nuisance.

With the introduction of the READ-XML / WRITE-XML methods we switched to using these (and having .xml files instead of .d files for table contents). With the stricter XML parsers (which refuse to load illegal xml characters like our favorite separator, CHR(1)) we switched to READ-JSON / WRITE-JSON (which automatically escape all the 'illegal' characters).

The (very) minor downside is that these methods do not work on a database buffer handle, so you need to use an intermediate temp-table which is CREATE-LIKEd the database table.