Help with Error "The shared memory is version 6413727; expected 13727 (1178)" Please

SquirrelHead

New Member
Hello,

I am trying to make a connection to a Progress database but am getting the following error message when attempting to connect.

"The shared memory is version 6413727; expected 13727 (1178)"

I am trying to connect on a Windows Server machine using the following command.

C:\oe117\bin\prowin32.exe D:\l\db\mydb -rx

When I run the above command I get the "Powered by Progress" splash appear but then instead of the tramlines I get the above error message on screen. I hit OK and am dropped back to the command prompt.

Based on searches I believe this is caused by a mismatch between the versions of client and server. This is a third party system and whilst I know how to write and compile progress scripts to analyse the data I know very little about the actual workings of progress!

Can someone please help point me in the right direction as I have been trying to sort this for a few days now and am at the point of pulling out what little hair I have left.

Thank you

Regards

Squirrel
 

Cringer

ProgressTalk.com Moderator
Staff member
You're absolutely right that this is a version mismatch issue.
Looking at the numbers I'd hazard a guess that the database is served with 64 bit Progress, and you're using the 32 bit executable. Is there a prowin.exe somewhere on the server? Try using that.
 

SquirrelHead

New Member
Hi there,

Thanks so much for taking the time to reply to me. Really appreciate help with this.

There are three folders on the server that appear to contain progress code. These are:

\oe102b
\oe117
\oe117_x64

I have tried running prowin32.exe which is located in both \oe102b\bin and in \oe117\bin. This results in the shared memory error.

I have also tried running the prowin.exe which is located in \oe117_x64\bin. This generates a different error, as follows:

Unable to open or create d:\l\db\mydb.lg, error 13 (2257) dbDelUsrctl: SemLockLog ret = -1

There is a link on the desktop on the server that starts up a session to the software and this is working. That points to \oe117\bin\prowin32.exe and works. If I click on the link a database login pops up on screen but that is for the front end.

Up until the software was upgraded we were able to run the tramlines without any issue. I can still access the tramlines now if i do not add the database into the command line. As soon as I try to start with a database then the shared memory error appears.

Thanks again

Squirrel
 

TomBascom

Curmudgeon
You have to use the *exact* same path name for both prowin and proserve. If the name provided to proserve was relative you may need to change working directories first.
 

andre42

Member
For a description of the version number scheme have a look at Progress KB - What is the Shared Memory version number for each Progress OpenEdge version?
13727 means 11.7.2 (ie. 11.7 SP2), 6413727 means 11.7.2 64 bit. Don't bother with the \oe102b path.
I suppose \oe117_x64\bin\prowin.exe is the correct executable, you should probably debug the following error message. It seems that d:\l\db\mydb.db is the database. In that case a client accessing the database through shared memory seems to need write access to the database log. Maybe it is sufficient to use a different Windows user.
The other option would be to access the database using TCP/IP, which should work either through the 32 bit executable or through the 64 bit executable. You would have to find out the connect string instead of just giving the path to the database.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
As others have said, your original error was because you were attempting a shared-memory connection with a 32-bit client to a database opened with a 64-bit broker. Only a 64-bit client can do this.

I have also tried running the prowin.exe which is located in \oe117_x64\bin. This generates a different error, as follows:

Unable to open or create d:\l\db\mydb.lg, error 13 (2257) dbDelUsrctl: SemLockLog ret = -1
Your userid doesn't have write permission on the database log.

There is a link on the desktop on the server that starts up a session to the software and this is working. That points to \oe117\bin\prowin32.exe and works.
That client must be using "-S <4GL broker service name or port number>" in its startup or connection parameters. It is connecting via TCP, not shared memory. A 32-bit client is allowed to connect via TCP to a database started with a 64-bit broker.

If I click on the link a database login pops up on screen but that is for the front end.
I'm not sure what else you expect. Do you mean that it is an application client as opposed to, say, a procedure editor?

Up until the software was upgraded we were able to run the tramlines without any issue. I can still access the tramlines now if i do not add the database into the command line. As soon as I try to start with a database then the shared memory error appears.
When you talk about "the tramlines", do you mean the character procedure editor? That should still be available to you in a proenv session by running _progres.exe. Note however that it is also a 32-bit client so you will need to connect to this database via TCP, i.e. using -S with the broker port number or service name, either on the command line or in the database connection dialog.

From context, I am guessing that prior to your software upgrade your database was opened with 32-bit executables, meaning that 32-bit clients could make shared-memory connections.
 

SquirrelHead

New Member
Hello

Thank you again for the replies.

Is there anyway to know what path was used when the server was started ?

I have tried using a TCP/IP connection as saw that mentioned on a web page at one point when I was searching trying to find a solution. I have a "ini" file that has the following settings in it.

SystemName=live
ServerHost=localhost
ServerNetwork=TCP
ServerCacheDir=.\cache
ServerLogConnectFile=
(plus a whole heap of other stuff)

The following works and starts the tramlines.

C:\oe117\bin\prowin32.exe -ininame myini.ini -basekey INI -rx

But as soon as I add a database to the line it generates the same shared memory error.

C:\oe117\bin\prowin32.exe -ininame myini.ini -basekey INI D:\l\db\mydb -rx

I have asked for the user that I am connecting with to be set as an administrator on the server. I am not sure if this will be permitted or not as we are a third party supplier to the organisation. Will wait and see what they say in respect to the privilidges.

Is my TCP/IP connection correct or do I need to do something else in order to make Progress connect via TCP/IP?

Thanks again for help here.

Cheers

Squirrel
 

SquirrelHead

New Member
Hi again,

I meant to also ask, is there a way to find out the broker port number used when the server was started ? There are two config files on this server, one is an "ini" and the other is a "pf". I can't see a port number in either of these.

Out of interest, the pf file under the oe102b install included a -db switch that indicated the location of the database. The pf file for the oe117 install no longer includes this. So I am guessing this reinforces the idea that the connections made by others are indeed TCP/IP.

Thanks

Squirrel
 

SquirrelHead

New Member
Hi again,

Some extra context of what we are doing and the issues we have.

The Progress system is a software deployment by an external company. They install/maintain the software and provide us with desktop shortcuts that provide a means of accessing the front end of the system.

We have a set of Progress scripts that interrogate the progress databases directly. These scripts dump data to text files that we then build reports from to create our key performance indicators. The scripts are compiled against the database and run via a batch file on an overnight scheduler.

We create these scripts ourselves as it would cost a fortune to have the software developer create them for us especially as the KPI's change frequently.

As things stand right now I am unable to recompile our scripts following the upgrade by the supplier either via command line or via the tramlines.

In case it helps at all, the following is the Target line in the shortcut:

C:\oe117\bin\prowin32.exe -ininame myini.ini -basekey INI -pf startup.pf -p start.p

The Start In folder in the shortcut contains the three files identified above, namely:

myini.ini
startup.pf
start.p


Thanks

Squirrel
 

Cringer

ProgressTalk.com Moderator
Staff member
Unable to open or create d:\l\db\mydb.lg, error 13 (2257) dbDelUsrctl: SemLockLog ret = -1
Squirrel

I'm pretty sure this is because the database has been served using an account with admin rights, but you haven't elevated your proenv/cmd to administrator rights.
 

Cringer

ProgressTalk.com Moderator
Staff member
C:\oe117\bin\prowin32.exe -ininame myini.ini -basekey INI -pf startup.pf -p start.p
The startup.pf file will probably contain the -H, -S, etc settings you need to get a client/server connection to the database from the command line.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Is there anyway to know what path was used when the server was started ?
I assume you mean the path of the OpenEdge executable. Run Resource Monitor (Start | Run | resmon). On the CPU tab, do a handle search for "sharemem". You will see one line per database shared memory segment. It will tell you the process ID of the broker process (_mprosrv.exe). Task Manager will tell you the path to the image.

The following works and starts the tramlines.

C:\oe117\bin\prowin32.exe -ininame myini.ini -basekey INI -rx
You haven't clarified "tramlines". I suspect this is just starting an editor with no database connection.

Is my TCP/IP connection correct or do I need to do something else in order to make Progress connect via TCP/IP?
I don't see evidence of a TCP/IP connection.

I meant to also ask, is there a way to find out the broker port number used when the server was started ?
Once you know the fully qualified path of the OE database executables and the database, run proenv with the appropriate OE version and run promon against the database. Promon R&D 1 17 (Servers by Broker) will show you the port number of each broker, together with their PIDs.

There are two config files on this server, one is an "ini" and the other is a "pf". I can't see a port number in either of these.
A .ini file contains options that configure a client. A .pf (parameter file) contains startup parameters that would otherwise be in the command line of either a client or a broker. A port number would be in a .pf file, with the "-S" parameter.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
The Progress system is a software deployment by an external company.
We have a set of Progress scripts that interrogate the progress databases directly. These scripts dump data to text files that we then build reports from to create our key performance indicators.
We create these scripts ourselves as it would cost a fortune to have the software developer create them for us especially as the KPI's change frequently.

Is the vendor aware that you are doing this?
Do you have the appropriate licensing to do this?
Are you aware of the impact these "scripts" have on the database and on the vendor's application? Can you measure it?
 

SquirrelHead

New Member
The startup.pf file will probably contain the -H, -S, etc settings you need to get a client/server connection to the database from the command line.

There are no -H setting or -S settings in the .pf file.

The .pf contains:

-d dmy
-Bt 512
-h 10
-D 500
-nb 100
-s 128
-l 1024
-expandbrow
-q
-wy


Thanks
 

SquirrelHead

New Member
You haven't clarified "tramlines". I suspect this is just starting an editor with no database connection.

Yes, I think this is the Progress Procedure Editor. If I click on the Help menu item it shows "Procedure Editor" so assuming we are talking about the same thing.

I don't see evidence of a TCP/IP connection.

I suspect it is not a TCP/IP connection, I am unsure though.

I will be back onto this tomorrow. Have asked for our user to be checked to ensure we have right privileges.

Thanks
 

SquirrelHead

New Member
Is the vendor aware that you are doing this?
Do you have the appropriate licensing to do this?
Are you aware of the impact these "scripts" have on the database and on the vendor's application? Can you measure it?

Yes, the vendor is aware. We have an agreement in place that our scripts will be read only and only ever dump text out of the system. I should probably add that the vendor has a minimum charge for any development work no matter how trivial. They are a large corporation, we are not. I cannot afford their fees.

Yes, we have the relevant license to use XCODE to encode our scripts and run them against the system.

Impact is negligible as all we ever do is dump data to text files. We have been doing this for over fifteen years now without issue.

Regards

Squirrel
 
Last edited:

Cringer

ProgressTalk.com Moderator
Staff member
In the database.lg file, search for the last entry of (333). This was the last time the database was started. After that come all the database startup parameters. There should, hopefully, be a -S setting there. Then you can:
prowin32 dbname -H localhost -S xxxxx
 

SquirrelHead

New Member
Hello everyone

Today we had the user added to the Administrators group. I then tried again with the local version of 64 bit progress and we have been able to compile and run our extracts.

So my problem was two-fold really.

1 - I had to get our user account added to the Administrators group
2 - Stop using 32 bit prowin32.exe and start using 64 bit prowin.exe

This is a fantastic result for us and couldn't have been done without all your help. I am truly grateful. I wish I could give something back to this forum for all your help but sadly I know next to nothing about Progress!

I will mark Cringer's answer as Best Answer as they were first to mention the versions. But really I wish I could mark you all as Best Answer :)

Thanks again for all your help. I really do appreciate it.

Regards

Squirrel
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
We know from your database shared memory version that your database was opened with a 64-bit broker. Thus shared memory connections are possible only with 64-bit clients, e.g. prowin.exe.

There are two ways a client can connect to a database. The first is to connect at startup, either by directly specifying a -S parameter on its command line, or by indirectly specifying it, in a .pf file that is in turn referenced on the command line (e.g. "-pf myparams.pf").

The second way is to start without a database connection and then to connect programmatically via the ABL's CONNECT statement.
OpenEdge 11.7 Documentation
 

Cringer

ProgressTalk.com Moderator
Staff member
Glad you got it sorted Squirrel. That's what the community is for. :)
You should consider coming to one of the PUG Challenge events to learn more about Progress. We love it. Oh and we drink plenty of beers too.
 
Top