9 replies to this topic

[c.reid]

Firstly, I know next to nothing about PROIV. I very humbly request that any explanations and help given be written as though you are speaking to a 5 year old (well at least when it comes to the PROIV stuff). I'm a sysadmin with a managed IT company and we do some work for a small power equipment shop. They recent moved off of using PROIV 5.5 to a complete new system and a new server, the new system is called Point-of-Rental but that information isn't really necessary.

We decided to keep the old server that was hosting PROIV on the network so that they could access it still to reconcile any accounting or old information they needed, and of course a week ago the box completely took a crap. Motherboard is dead. In the interest that they only need access to it for a few weeks or months, I decided the best course of action was to virtualize the old HDD, trying to recreate it as exactly as possible with the data so that, in theory, all the client connections would just work and all would be well.

The good news is, I successfully imaged the C drive and the secondary storage drive where some of the PROIV folders were shared from (pro4data, p4draw). The images were imported into a virtual machine running on the newer server. Everything is exactly as it was as far as the server is concerned. Got my hopes up, went to open PROIV and was greeted with "Data File Check in Progress" - logins are disabled until the data check has finished. I'll list out all the messages in hopes of getting some insight. Again, I am not well versed in the slightest in this program, so please elaborate

00001 ischk errors
00002 -------------------
00003 Last Run: Thu Nov 29 01:0015 2012
00004 E:\PRO4DATA\inwrk1.pro:
00005 Unallocated page: Page 0x481
00006 Unallocated page: Page0xdf4
00007 E:\PRO4DATA\rspfk3.pro:
00008 Unallocated page: Page 0x163
00009
00010 PageSize Errors
00011 ------------------------
00012 Last Run: Thu Nov 29 01:00:15 2012
00013 E:\PRO4DATA : E:\PRO4DATA\glgl.pro: Near max (10041Kb left)
00014 E:\PRO4DATA\tmpdir : E:\PRO4DATA \tmpdir\rspo20f.pro: Near max (0Kb left)
00015 E:\PRO4DATA\tmpdir : E:\PRO4DATA \tmpdir\rspo20i.pro: Near max (17847Kb left)
00016




I cannot get passed this, the only thing I can do is hit Discard changes and exit which opens up the "/ To Continue" box and then after entering "/" the program window closes out.

So sorry for the super long post, any help will be amazingly appreciated!

Attached Thumbnails

• 

[DARREN]

The screen you are seeing is within the application so you have successfully installed and logged in. It appears that the application has been programmed to check the size of the Pro-ISAM files it references.

The ischk utility (Index Sequential Check) is a utility program that accompanies PROIV. As it's name implies, it checks the integrity of the ISAM file(s). You will need to locate this executable along with several others to resolve this (they will be on the machine somewhere). They are namely: -

iskeys.exe
isout.exe
isin.exe
iscr.exe

Note that I have not worked with PROIV and Windows for a long time (we are Linux) so the routines may actually called something like isout32.exe etc.

Change directory to the E:\PRO4DATA \tmpdir directory. Back up the offending files.

run the command iskeys {filename}.pro | more
This will give you the 'key size' of the file.
run the command isout {filename}.out {filename}.pro This will create an ASCII text file of the ISAM file.
run the command iscr -k{n} (where n is they key length obtained previously) -r3000 {filename}.pro
isin {filename}.out This will restore the data back into the ISAM file from the ASCII file.

repeat for the other file.

Also see the thread http://www.proivrc.c...&t=2402&hl=iscr

The above thread has all you need to know about the 'is' utilities.

Hope this helps.

Darren

[DARREN]

Reading your post more carefully it appears that the offending files are inwrk1.pro and rspfk3.pro that are located in the PRODATA directory. The procedure to correct these is the same. I would also run the ischk against all the ISAM files to ensure no others are corrupted. i.e. ischk.exe *.pro You can use a -y option and that will force the utility to attempt to auto correct the data.

Regards

Darren

[c.reid]

Reading your post more carefully it appears that the offending files are inwrk1.pro and rspfk3.pro that are located in the PRODATA directory. The procedure to correct these is the same. I would also run the ischk against all the ISAM files to ensure no others are corrupted. i.e. ischk.exe *.pro You can use a -y option and that will force the utility to attempt to auto correct the data.

Regards

Darren

Thanks so much for your reply. Am I running ischk.exe *.pro -y from a command line, or is there a utility within the SCSBIN folder that I should be looking for?

[c.reid]

Actually I figured it out. running the command from within the scsbin folder and pointing it at the offenders.

it found the errors in inwrk1.pro and i hit yes on rebuild and it said unable to rebuild now what?

[DARREN]

You have to perform the procedure I documented previously (iskeys, isout, iscr, isin). That 'should' recover the file. Failing that you may need to call PROIV direct, as they can repair bad index's.

[c.reid]

You have to perform the procedure I documented previously (iskeys, isout, iscr, isin). That 'should' recover the file. Failing that you may need to call PROIV direct, as they can repair bad index's.

Somehow I completely missed that initial post and only saw the second. Thanks so much, I'll try it out and report back.

[c.reid]

You have to perform the procedure I documented previously (iskeys, isout, iscr, isin). That 'should' recover the file. Failing that you may need to call PROIV direct, as they can repair bad index's.

ok, i am getting an error during the iscr phase regarding both files. all the steps before and after that you mentioned are working fine though.

running the command "iscr32.exe -k47 -r3000 e:\pro4data\inwrk1.pro" (for the first file) yields an error message of "iscr: error creating e:\pro4data\inwrk1.pro; FS_UNEXPECTED: Unexpected error conditions. [134 - Can not get the request handle pointer]."

any additional magic you may know of that can fix this? i did run the ischk.exe after i did the steps but I still get the exact same error log at login, i assume because of the iscr error i am receiving. i feel so close to fixing this.

[DARREN]

Confirm that iscr32.exe is working by itself e.g. iscr32.exe -k10 -r1500 myfile.pro
Ensure you path includes the location of the executables

There is another option that works with iscr called -e (empty). you could give that a try.

[c.reid]

Confirm that iscr32.exe is working by itself e.g. iscr32.exe -k10 -r1500 myfile.pro
Ensure you path includes the location of the executables

There is another option that works with iscr called -e (empty). you could give that a try.

-e didn't seem to do anything at all. I appreciate all the help, I feel as if there may be nothing I can do to get the database back up and running. the only other thing I was thinking is you mentioned originally that "it looks like your proiv is set to check the files at launch" is there a way I can tell it not too? and hope that it gives me access to some of the data?