Broker Rejects Connection

[dlangschied]

I have an issue that needs clarification.

I have SQL setup on a test database. For some reason, it started rejecting SQL connections. This database is a restore of our production system each Saturday. I am not sure if it was the restore that caused the issue or it was something else.

Any ideas?

 

[RealHeavyDude]

It would be helpful when you would tell us what Progress/OpenEdge version you are talking about and exactly what error message it is you are getting.

RealHeavyDude.

 

[dlangschied]

Is not the knowledge of RealHeavyDude all encompassing? LOL

The version of Progress is OE10.1C. In terms of the error message, there was no associated number just the message in a warning box prefixed by the ODBC connection info, [DataDirect][ODBC Progress OpenEdge Wire Protocol Driver][OPENEDGE].

 

[RealHeavyDude]

Every SQL92 connection to a Progress OpenEdge database requires user credentials that have corresponding rights granted.

There are several facts that need to be considered when introducing SQL clients to a Progress database:

1. The Progress database is no SQL database in the first place - its a 4GL database. It is particular about mixing and matching 4GL and SQL functionality with the respective engines. That means all SQL privileges need to be set up regardless how security is set up on the 4GL side.
2. The 4GL engine utilizes a revoke philosophy whereas the SQL engine goes with the grant philosophy. That means: You don't grant it you can't access it.
3. Users in the 4GL _User meta-schema are meaningless to the SQL engine with 1 exception.

In order to access a the database via the SQL engine the first time you have two options for the user credentials:

1. The credentials of the OS account under which the database was created. This account is considered to be the "owner" of the database and has DBA privileges per default.
2. The credentials of the account SYSPROGRESS created in the _User with the 4GL data administration tool ( that's the exception I was referring to above ). This account is granted DBA privileges per default.

When you've established a SQL connection to the database with either one of the above accounts you can then from there on

• Grant users that exist in the 4GL _User table privileges - which makes them known to the SQL engine
• Create users with the SQL CREATE USER statement and grant them privileges.

The restored copy of the production database might not contain any of the above.

By the way: Do you have 4GL and SQL clients connecting to the database? If yes, did you consider to set up a secondary login broker so that each client type ( 4GL or SQL ) connects to its dedicated login broker?

Heavy Regards, RealHeavyDude.

 

[dlangschied]

I have made the necessary changes to my development and test environments to have 4GL and SQL only servers running. The next time I have to do a restore of production to either of these environments, I will see if I continue to get broker rejections when the database and the subsequent SQL broker server are started.

Thanks!