Hi!
We have problem with missing variables.
Client (Windows application) is connecting to database network server by
ODBC. After it is connected, we create some global variables for session in
our start procedure, for example:
create variable UV_MPRESS2_BUILDNUMBER integer;

Under ASA 7, 8, 9 and application deployed in PowerBuilder 7.0 we have no
problem, but now, when we migrated our client application do PowerBuilder
11.5 and ASA 11, we have problem with missing variables.
Client is not disconnected and works normal, but when it tries to get access
to variables, it gets error "column V_MPRESS2_BUILDNUMBER not found". We use
variables in triggers, views, stored procedures and functions in database
and inside client application.
It looks like total destroying of global variables for session.
What can be a problem?

Best regards!
Krzysztof Korolonek
Soft4Media

Can you narrow this down to a specific statement/operation?

The only thing I am seeing is that the error may be correct.
According to the create variable statement shown and the
error text being thrown, you are actually comparing two
different identifiers. The latter one is missing the first 'U'
character.

Using a request level logging of the issue [-zr SQL+Hostvars
added to the server command line or calling sa_server_option( ) ]
may provide some clarity of how the server is behaving.

But since you have also changed teh PB version maybe they
way the PBScripts and datawindows ported may be a bigger
part of this.

"Krzysztof Korolonek" <krzysztof.korolonek (AT) fibermedia (DOT) pl> wrote

The correct error text is:
"column UV_MPRESS2_BUILDNUMBER not found"
It was my mistake. These are the same identifiers.

The error comes from database, especially from triggers. It looks like
something is droping variables but not disconnecting client, or database
sever re-connects automaticaly with client after droping connection with new
connection but it can't create variables again, becouse it is coused only
from client application.

I will try with -zr.

Best regards!
K.Korolonek

Another guess might be, what was once done on one
connection may be now spread across two or more
connections; the latter not benefitting from any create
variable operations on the first connection.

It may also be possible that a part of the code that
creates those is not firing now that PB have been
migrated.

Good luck with your investigations on this.




"Krzysztof Korolonek" <krzysztof.korolonek (AT) fibermedia (DOT) pl> wrote

We have just notified that there is the same problem with global temporary
tables. All data has gone from temporary tables, but client has not been
disconnected from database server! Client application is still working.
It looks like server drops connection and creates it again without breaking
connection with client application.
There are many clients working on this server in the same time (about
150-200). Connections comes from different IP places by VPN network. Can it
by problem of timeouts or deadlocks?

K.Korolonek

This sounds like you are using some form of connection pooling. Could
that be the case?

Glenn

Krzysztof Korolonek wrote:
--
Glenn Paulley
Director, Engineering (Query Processing)
Sybase iAnywhere

Blog: http://iablog.sybase.com/paulley

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports: http://case-express.sybase.com

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the
Sybase iAnywhere pages at
http://www.sybase.com/products/datab...chnicalsupport

1) By ODBC from standard windows client application (PB11.5). Users connect
to dabase using database logins, no pooling.
2) By WWW application (MS VS.NET) using SQL Anywhere .NET Data Provider
(with pooling) or OLE.DB (no pooling). One login for all users.

One database but 2 different systems connected.

But problem is only with the first system.

Moreover we noticed connection terminated messages on the server console
(look attachement). But client is still working despite the fact that
disconnected message appeared on the console.

Best regards!
K.Korolonek

SQL Anywhere does not automatically re-connect terminated connections.

Once an application has disconnected, that connection's context
vanishes. If the application re-connects, they will get a new connection
with a new context (that is, no "global" variables will be defined, the
contents of global temporary tables for this new connection will be empty).

Does your PB application support automatically re-connecting to the
server in case of an error?

Glenn

Krzysztof Korolonek wrote:
--
Glenn Paulley
Director, Engineering (Query Processing)
Sybase iAnywhere

Blog: http://iablog.sybase.com/paulley

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports: http://case-express.sybase.com

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the
Sybase iAnywhere pages at
http://www.sybase.com/products/datab...chnicalsupport