Question Proper way to enable SQL?

kemic

New Member
I've got an old 9.1e instance that was never intended to be used with SQL. I've successfully got the JDBC driver talking with Squirrel SQL but I wanted to verify with some experts that I've set this up properly. I do NOT want to impact any of the 4GL clients.

I've used the following two URLs as reference for what I've done so far (I don't think I can post links yet...).
knowledgebase.progress...How-to-set-up-a-secondary-login-broker-for-SQL-92-connections-for-Progress-OpenEdge-database
knowledgebase.progress...How-to-connect-SQuirreL-SQL-Client-to-Progress-OpenEdge-DB

To create the secondary login broker:
  1. Connected to the AdminServ with Progress Explorer
  2. Created a new Database (DBName_SQL) alongside of my existing database (DBName)
  3. Edited the defaultConfig on the new database to add the -m3 server argument.
  4. Edited the defaultServerGroup under the defaultConfig to be: SQL only, listening on port 8000, 5 servers, 5 clients per server max, 5 clients per server min, 8001 min port, and 8005 max port.
When I start the second database it times out in Progress Explorer but I can still connect via JDBC and Squirrel SQL with out issue. I wanted to check to make sure this is the correct way to configure it before moving this configuration to production. I've inherited this old database and we're somewhat locked into the proprietary application using it (no upgrade insight...). My goal is to be able to get some data out of it with out impacting or relying on the proprietary application.

Thanks for taking the time to read this! Stay safe out there...
 

TomBascom

Curmudgeon
Given the constraints, your approach appears to be solid. From a terminology perspective you are not, however, creating a new database. You are adding a secondary login broker to provide access to an existing database.

Progress 9.1e is ancient, obsolete and unsupported. Your data is at risk. If you are working for a public company the shareholders ought to sue management for criminal negligence.

If you have the application source code (which is very common) and can compile it there is no technical barrier to upgrading. Vendor claims that they only support 9.1 (or whatever) are specious. Whatever "support" they are providing is of little or no value and is certainly not improved by staying on a release that is 20+ years old.
 

sw2000s

New Member
I aggre with Tom Progress 9.1 is too old for any idea is not support.

but about the ODBC connection if you only have less odbc /jdbc client , you can connect ODBC in same 4GL broker .

we use 4GL and ODBC connection in same broker. it is easy way.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
you can connect ODBC in same 4GL broker
If you can connect a SQL client then it isn't a 4GL broker; it's a multi-protocol broker (i.e. -ServerType BOTH).

we use 4GL and ODBC connection in same broker. it is easy way.
Easy <> correct.

The "easy" way (i.e. provisioning a multi-protocol broker) seems easy until something unexpected happens, like user behaviour changes or there is a port conflict or a server fails to spawn. Then it rapidly becomes harder to troubleshoot than if you had done things correctly in the first place, which isn't difficult or time-consuming.

Using a single broker for both 4GL and SQL servers is a worst practice.
 

TomBascom

Curmudgeon
What Rob said.

It may be "easy" but your users won't appreciate that when problems occur and it takes you longer to resolve (or completely avoid) them than it would of had you only done things the "not really much harder at all" way.
 

sw2000s

New Member
Yes. we have face some ODBC BUG, but i am not sure , is that relater use same broker.

The ODBC connection cause Database Cash. when one ODBC close connection and the other ODBC login at same time.

we have consider splinter the other on broker only for ODBC , but need change many other system connection . at last we give up.

spliter two brobker is the best choice when you are the beginning. just like Rob and Tom subjection .
 

kemic

New Member
Thanks for the replies. I may have to pick your brains later about some client performance issues (Win7 vs Win10) we're facing as well. But that'll be a new topic... :)

As for the source code, the client comes over as an exe file and after installation there's a number of .pl and .wrx files in the install directories. These appear to be binary files. A quick google seems to imply it might be possible to decompile?

Thanks again!
 

TomBascom

Curmudgeon
There is a decompiler service available. It is not intended to enable piracy but rather to help people to recover source code that they have somehow managed to lose. You need to be able to establish that you have a legal right to the source.

The .pl is a "Progress Library". You can use "prolib libname.pl -list" to see the details. It may, or may not, contain .p, .w, and .i files as well as .r files. Dot-r is compiled code. Dot-p etc is source. It is also possible that whatever you are installing at clients was packaged up without source just to keep it smaller -- you might still have the source somewhere and be unaware of it.
 

kemic

New Member
OK, everything worked well until we rebooted. As far as I can tell it looks like the secondary SQL only broker is trying to startup first. Which is having an error because the main broker is not running yet. Is there any way to control the order the Admin Service starts brokers in? For now I just manually start up the secondary broker when needed.

Unfortunately sometimes starting the secondary broker manually causes an error related to user count. Currently the -n parameter is set to 60 (main broker). I haven't researched much yet so I may fix it on my own but any info about this error will be welcomed.

Error Message: You have attempted to connect to a database with too many users connected to it. Retry the connection later, or increase -n on the server.

Thanks for the help!
 

kemic

New Member
Thanks for all the replies... Looks like I'm limited by the workgroup user license. No matter how I tune the server startup options, it looks like I'm still bound by the licensed user count... So once everyone gets connected to and is using the database, the SQL broker will not start.
 

TomBascom

Curmudgeon
Yes, that would be true.

You could, possibly, do something like limit the 4gl connections to 40 and allow 20 SQL connections. Or you could upgrade to a less restrictive license and more connections.
 

tamhas

ProgressTalk.com Sponsor
Note that -n is not the same thing as licensed user count. It might be worth reviewing your type of user license, who is actually using it in which way (e.g., multiple sessions by the same person or on the same device), and the like. This might allow you to either raise -n and still be within the terms of your license or, if you find that you actually need more users, to increase your license.
 

tamhas

ProgressTalk.com Sponsor
BTW, if that is the case, it seems like a strong argument for getting off of Workgroup on general principles.
 

Cringer

ProgressTalk.com Moderator
Staff member
There's more reasons than that. There are some serious limitations on scalability baked into the license. Performance tuning is more a case of limiting the negative factors rather than enhancing things. Workgroup should never have been sold to anyone with more than about 5 concurrent users IMO. And even then...
 

tamhas

ProgressTalk.com Sponsor
That was my point. If one is at that kind of limit, then there are bound to be many compelling reasons to switch to Enerprise.
 
Top