All righty then!
Lanpak 9.0
Ledger 9.0A 20080402
Ran Data Integrity on ALL modules and no errors were found (except 1 or 2 in GL re: missing acct#s)

On 5/6/08 the client attempted to perform an upgrade (Lanpak and GL 9.A) They unfortunately performed this function while logged into the server.

They called when they were unable to convert the GL. Kept hanging @ "Security User...". I walked them through a complete uninstall and re-install of Ledger 9. Install appeared successful but attempts to convert the data resulted in error "Error - Internal Error: field number is out of range. Occurred while attempting to append record to account group file". Peformed a search on the forum and realized that the problem was caused possible b/c of the server installation.

As per most of the post, I had them check the \Softrak\dict "L90AR & L90AI" files as well as the \qrasp "QRTALZ90 & QRALW90" files. They all had the install date of 5/6/08 which was the date of the install on the server.

Today I renamed the above mentioned files. I also found other files in the \qrasp folder with the installation date stamp and renamed those. Ran the unwise.exe in the Softrak\ledger dir, and then deleted the entire \Softrak\Ledger dir. Peformed the update. Logged into GL 9.0 and attempted to convert the data.
"Conversion failed: Error occurred when checking existance of the GL fiscal years data".

I've checked ALL the \Softrak\ directories for the program files with the install date of 5/6/08 - the date the install was performed from the server. I renamed those files .old. I've also uinstalled Lanpak and Ledger after changing files to .old and re-installed both. Got the same error as mentioned above.

These were the files affected and renamed:
M:\qrasp = QRTALW90, QRTALZ90, QRSSMZ90, QRTALZ90, QRTSMZ90
M:\Softrak\dict = L90AR, L90AI
M:\Softrak\system\qrasp\AL = QRTALW90, QRTALZ90, QRTSMZ90

After the re-install only files remaining with the server install date stamp:
M:\Softrak\system\lanpak = lanpak.chm, lanpakselectionuninstall
M:|Softrak\system = ADS.cfg, chksys.exe

Where should we go from here?

Hi, PwC,

You're correct that the problems initiated with performing installs at the server, rather than from a workstation connected to the server via a LAN.

The conversion error you're receiving indicates that the GL8.x data was not converted properly. It has been known to occur when someone has begun conversion of their data and then inter-
rupted/cancelled the process midway. This probably occurred the very first time the conversion began.

As a result, their data now contains some GL9 files mixed in with their GL8 files.

Do you/they have the backup they made of their GL8.x data immediately prior to doing the upgrade/initial conversion to GL9?

Have they done much/any work in GL since the upgrade? I ask becasue the easiest remedy is to backup the GL data they have then delete just the GL data (or move the existing GL data to another folder). Then, restore the backup of GL8.x data they made immediately prior to upgrading and beginning the first conversion. When they open GL9 next, they will receive the data is not compatible, do you wish to convert message again. They should reconvert their GL8.x data and carry on.

The lanpak.chm file is the lanpak help file. Does chksys still run okay?

So you know, we recommend that (rather than running the unwise.exe in the module folder) modules are uninstalled by running the Windows Control Panel Add/Remove Programs function. This means running it this program to 'uninstall' at the server. Installation would still be done from a workstation as you correctly did though.

Ummmmmmmmm, probably should have mentioned that I had them email me their data last week and I was able to convert it sucessfully on my system.

I'm going to try again with a backup from today and see where that takes us.

If I'm able to convert the data on my system and then download it back to there's are there any downsides to this that we need to consider?

The upside is that they will be further along than they currently are.

The downside is that whatever scenario that is preventing a successful data conversion may also prevent one or more other scenarios. And that can't yet be determined until they try.

It's certainly worthwhile to send them back the converted data (perhaps in a 'test area' to start with) and then go live if nothing immediately obvious occurs - making plenty of backups to start with.

We've been discussing this directly, and even sample data cannot be converted successfully at the client site. An error 1212 occurs and the data conversion stops at the Security Group files.

The clients dictionary directory had virtually all files with an October 10 2007 date, meaning that the installations have not yet been fully cleaned up. One or more of the dictionaries may be wrong and getting in the way. Not just Ledger 90A but all their Adagio programs need to be cleaned up.

Just an FYI to close this.....

5/16: Per Softrak, we replaced the client's \Softrak\dict\ directory with a copy from my system (ensuring of course that both the client and I had the same versions installed). Once we did this the conversion went without any further glitches.