ODBC query to _audit-detail causes 4GL error: 'SETUSERID

I now suspect either the 1 minute running ODBC query or a 4 minute running proutil command:

proutil auditarchive

 could be causing this..  Surely this native OpenEdge procedure isn't the cause?

Anyone?

No suggestions from anyone??

Is there anything I can do to help describe the problem better?

Description of this error 'SETUSERID of [db_name] requires that database to be connected (1072)'  is:

"You used the SETUSERID function specifying a logical database name:     SETUSERID( newuserid, password, logical-dbname ) but the logical database name you specified is not currently connected.  Connect to the database first."

So, what code are you using? Are you trying to read the contents of the _aud-detail table via SQL (ODBC)?

You are really trying to use the SETUSERID function for a SQL query? As I know, OE SQL does not have a capability like SETUSERID, currently available in OE ABL.

You probably need to open Case in Progress Technical Support. Do you have access to technical support?

Hey Valeriy,

Thanks for the response.  To add a bit of context...

We have a .net windows service that synchronises Progress database changes into a replica SQL Server database.  So we don't write any OpenEdge 4GL, we just query, via a Read Uncommitted ODBC connection, the OpenEdge audit tables and then run OpenEdge's archiveaudit routines.

The solution works well and doesn't affect the source OpenEdge system.

We have one particular customer who has a second OpenEdge application that is integrated with the same source OpenEdge system that we query.  They use shared 4GL procedure libraries to communicate with each other.

You're correct: we're not doing any ABL stuff so we're not calling SETUSERID.  It is this second OE application that experiences the exceptions.  The app that we query doesn't have any problems with our querying for data and our running auditarchive routines.

I believe that when we run a long running (minute or two) audit archive routine (and maybe the ODBC query) the second application runs into problems communicating with our source OE application.

Whilst we have dabbled in OE development we're not OE developers and our technical support ran out a few years back.

We have a number of Customers using our software, all successfully, and some with the same configuration of this second OE application communicating with our source app.  So I'm hoping it can be fixed with some OE server configuration changes...

Ок. I have no idea which OpenEdge server parameters can affect this.

As an option, you need to see the code of the second OE application, where the error occurs. For the second application session, you can enable advanced logging. Then reproduce the error, and see in which procedure and on which line the error occurred.

See ABL client session parameters "Client Logging (-clientlog)", "Debug Alert (-debugalert)", "Log Entry Types (-logentrytypes)" with 4GLMessages, 4GLTrace, DB.Connects options,  "Logging Level (-logginglevel)" with level 4 (Extended).

At a minimum, this will allow us to understand where the error occurs in the ABL code of the second application, and proceed from this point further.

I do not think the transaction isolation level on the side of ODBC somehow can influence the appearance of this error. It's possible that the second application is not connected to the database at this time, or it was for some reason disconnected from this database. Most likely, advanced logging will help to understand this.

In addition, it is worth looking at the log of your OpenEdge database, maybe there are some important messages there.