pemurray
asked on
Powerbuilder Datawindow Locking Issue
Greetings All,
Okay, it is easy to create a PB applications. But now that I am rolling them out, they seem to hang with the hourglass.
In one instance I have two versions of the application running on the same odbc connection. The first starts fine. The second application hangs. Is this to be expected?
Likewise, all of the users have a VB application that uses ODBC DSN 'number 1'
The powerbuilder application that I am giving them accesses the same ODBC DSN 'number 1'
It seems to work.
Can someone offer some guidelines for managing the datawindows to avoid conflicts? I don't want to roll out the application only to find that having a third user causes trouble.
The ODBC driver is a system dsn that accesses SQL Server via Named Pipes. (they are already set up on every system).
Thanks!!
PEM
Okay, it is easy to create a PB applications. But now that I am rolling them out, they seem to hang with the hourglass.
In one instance I have two versions of the application running on the same odbc connection. The first starts fine. The second application hangs. Is this to be expected?
Likewise, all of the users have a VB application that uses ODBC DSN 'number 1'
The powerbuilder application that I am giving them accesses the same ODBC DSN 'number 1'
It seems to work.
Can someone offer some guidelines for managing the datawindows to avoid conflicts? I don't want to roll out the application only to find that having a third user causes trouble.
The ODBC driver is a system dsn that accesses SQL Server via Named Pipes. (they are already set up on every system).
Thanks!!
PEM
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Michael,
Your suggestion to turn autocommit to true and explicitly start and end the transactions seems to be at odds with the help (shown below):
SQLCA.AutoCommit = value
Parameter Description value: Specifies whether PowerBuilder issues SQL statements outside or inside the scope of a transaction. Values are:
True PowerBuilder issues SQL statements outside the scope of a transaction. The statements are not part of a logical unit of work (LUW). If the SQL statement is successful, the DBMS updates the database immediately as if a COMMIT statement had been issued.·
False (Default) PowerBuilder issues SQL statements inside the scope of a transaction. PowerBuilder issues a BEGIN TRANSACTION statement at the start of the connection and issues another BEGIN TRANSACTION statement after each COMMIT or ROLLBACK statement is issued.
It seems like if I leave it as False, PB will handle the BEGIN, COMMIT or ROLLBACK for me.
What do you think?
To: Lordain,
There is a connection pooling tab on the odbc driver that has a default retry time of 120 for SQL Server.
Thanks!!
PEM
Your suggestion to turn autocommit to true and explicitly start and end the transactions seems to be at odds with the help (shown below):
SQLCA.AutoCommit = value
Parameter Description value: Specifies whether PowerBuilder issues SQL statements outside or inside the scope of a transaction. Values are:
True PowerBuilder issues SQL statements outside the scope of a transaction. The statements are not part of a logical unit of work (LUW). If the SQL statement is successful, the DBMS updates the database immediately as if a COMMIT statement had been issued.·
False (Default) PowerBuilder issues SQL statements inside the scope of a transaction. PowerBuilder issues a BEGIN TRANSACTION statement at the start of the connection and issues another BEGIN TRANSACTION statement after each COMMIT or ROLLBACK statement is issued.
It seems like if I leave it as False, PB will handle the BEGIN, COMMIT or ROLLBACK for me.
What do you think?
To: Lordain,
There is a connection pooling tab on the odbc driver that has a default retry time of 120 for SQL Server.
Thanks!!
PEM
ASKER
More...
It seem pretty apparent that my application is causing the users of the other application that accesses the same database to get an SQL Runtime Error 40002.
I can see that I am not going to be able to run this application until I do some more research. Of course the other program was written in VB and the developers probably thought they would have sole access to the database. But still, it is a multi-user app and there were no runtime errors until I rolled out my application (which I pulled back).
Thanks!
PEM
It seem pretty apparent that my application is causing the users of the other application that accesses the same database to get an SQL Runtime Error 40002.
I can see that I am not going to be able to run this application until I do some more research. Of course the other program was written in VB and the developers probably thought they would have sole access to the database. But still, it is a multi-user app and there were no runtime errors until I rolled out my application (which I pulled back).
Thanks!
PEM
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I am not in the office right now so I will have to check the settings. But the application uses a system odbc driver (as does the other application). The odbc driver connects to SQL Server via Windows NT Authentication for each user.
Thanks!!
PEM