Every other connection??

[Mike Derrick]

Hi all. I am hoping someone can help with an issue.

Symptom: 1. First connection from shortcut works. Close the app.
2. Second connection throws the "msgOpen: unable to open message file: PROMSGS" error message. Close the app.
3. Repeat steps 1 and 2 ad nauseum.

This is occurring after upgrading our client to a newer version of our app on 10.1C04. She's running "Client Networking" on XP Professional SP03 and making a Client/Server connection to a Workgroup database on a Windows 2003 server which was just upgraded as well. We use an INI file to set the environment on the Target line of the shortcut.

Note: The prior version, 10.1A02 did NOT uninstall - it hung on the "Removing Files" step. The Adminservice had already been shutdown. I ended the installer process, then deleted the installation directories and cleaned up the registry. Rebooted. 10.1C and SP04 installed cleanly. I rebooted again, unistalled, and RE-installed 10.1C04 with no errors. Still the same.

Another client running with the SAME configuration is working fine. However, his PC DID uninstall 10.1A02 properly.

what am I missing? Any ideas much appreciated!

 

[Stefan]

Check if any environment variables are still set (and pointing to the old installation). These should never be set (unless you like dealing with strange issues).

Are you sure the ini file you think is being targeted is actually being used? (add a nonsense dlc to that for a sanity check). If you only specify -ininame witout basekey INI for example I have seen issues where the registry will be used if it matches the ininame. Use an exotic ininame (sanity check again).
Are the references in the ini file correct?

Hopefully something is strange in here and you will get an actual message reporting why the second connection is failing.

 

[Mike Derrick]

Thanks for the reply Stefan. No environment variables are set. I am 99.999% sure the correct INI is being used - but I can try the nonsense DLC which is a good thought. I am definitely using the BASEKEY as well, the target string looks something like this:
< C:\DLC\101C\bin\prowin32.exe -p ui/com/wMain.w -pf bin\connect.pf -basekey INI -ininame bin\logsys.ini >

What's got me stumped is how it can work once, then not, then work again, etc. ... A locked file?? Dunno.

 

[Rob Fitzpatrick]

A few thoughts:

- I've run into "unable to open PROMSGS" errors with environment variables set improperly;
- your shortcut command line uses relative paths, so the starting directory value also matters; is it different on the client that works?
- I'm confused by the forward slashes in your starting procedure path; is that intentional?
- you're using a parameter file, so its content matters as well; have you checked that?
- when I have funky Windows errors and all else fails, I trace the app with Process Monitor. If you have a file locking issue you'll see it there.
- all that said, I have a feeling there may be something left of your 10.1A install that is causing this issue...

 

[Stefan]

Strange... and if you start the app a second time before closing the first?

If you remove all app and connection stuff and simply start a test.p which displays a message?

 

[Stefan]

A few thoughts:
- I'm confused by the forward slashes in your starting procedure path; is that intentional?

Nothing strange about that. Forward slashes can (and should always) be used, Progress does will translate forward slashes to the correct slash depending on the operating system, back slashes on *nix are escape characters so do not work. The forward slashes allow your same code to run on *nix. For a windows shortcut this does not really apply, but all our .p runs / includes are with forward slashes.

 

[Rob Fitzpatrick]

Nothing strange about that. Forward slashes can (and should always) be used, Progress does will translate forward slashes to the correct slash depending on the operating system, back slashes on *nix are escape characters so do not work. The forward slashes allow your same code to run on *nix. For a windows shortcut this does not really apply, but all our .p runs / includes are with forward slashes.

Fair enough. Portability concerns aren't top of mind for me when looking at Windows shortcut command lines.

 

[Mike Derrick]

Stefan / Rob,

Thanks for the input. It's application logic. Withouot getting too into it, I believe some connection procedures that have recently changed are improperly handling a write to the INI file on startup/shutdown or encountering an error and not releasing it - so it is locked and we are not picking up the settings (DLC, Propath, etc.) from the INI file on the next try because it can't be read...

Looks like I'll hit the debugger tomorrow AM when I'm back at the office.

Still not sure why the one client works all the time though - same code. (?? ) ...unless there's something different in the INI files? I'll check that too.

Anyway, thanks again.