Hi all,

I have a question concerning a DBRemoteSQL()-API change in
ASA version 8.0.3.

The corresponding doc ("Release Bulletin 803.pdf") points
out the following behavior change:

Warning messages now have W prefix.
Before this version, all warning and error messages had a
prefix of I or E. Warning messages now have a prefix of W.
This change affects dbmlsrv8, dbmlsync, dbremote, ssremote,
dbltm, and ssqueue.


So far, we have used SQL Remote replication with clients in
version 8.0.1 and 8.0.2.
The server for the consolidated db has run versions from
8.0.1 to the the latest 8.0.3 ebf in the meantime.

We have encapsulated the DBRemoteSQL()-API in our client
application and use the corresponding callbacks for messages
and errors to
a) analyse possible replication problems and
b) log the messages in a log file just as the DBRemote.exe
does.
The DBTools-DLL has been used with DB_TOOLS_VERSION_NUMBER =
8000 all the time.


Now we prepare to update our clients to 8.0.3 and have come
across the above issue.

My questions are:
1. The topics that are presented as warnings in 8.0.3 - have
they all been displayed as errors in 8.0.1/8.0.2? Or are
there any former info messages that are now treated as
warnings?

2. In version 8.0.3 the DBRemoteSQL()-API uses a new
callback warningrtn. Whereas the use of this new callback is
easily to guess - what happens if I do the following:
Run the DBTools-DLL in version 8.0.3.xxxx with
DB_TOOLS_VERSION_NUMBER = 8000?
Will it use the warningrtn callback or will it still treat
warnings as errors and call the errorrtn callback as in
8.0.1?

The background of these questions is:
Do I have to change our app and use the warningrtn callback
when I want to analyse warnings in 8.0.3?
Or will they be returned via the errorrtn as in former
versions if I still use the DB_TOOLS_VERSION_NUMBER = 8000?


TIA

Volker

I believe that by setting DB_TOOLS_VERSION_NUMBER = 8000, that your client
application will behave as a v8.0.0 dbremote, so it should work as it always
has in the past, regardless of the version of the database enigne that you
are connecting to.

--
Reg Domaratzki, Sybase iAnywhere Solutions
Sybase Certified Professional - Sybase ASA Developer Version 8
Please reply only to the newsgroup

iAnywhere Developer Community : http://www.ianywhere.com/developer
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
ASA Patches and EBFs : http://downloads.sybase.com/swd/base.do
-> Choose SQL Anywhere Studio
-> Set filter to "Display ALL platforms IN ALL MONTHS"


<Volker Barth> wrote

Hi Reg,

thanks for your response.

Well, I have done some testing - unfortunately not very
systematically - , and I had the impression that the
behaviour was not absolutely as with 8.0.1.
So I will have to work further on that.

One further question: Is there any documentation on what
type of messages SQL Remote will generate?
In order to analyse possible problems, I have tried to
collect especially the messages that hint at such problems.
I have extracted them from SQL Remote logs.
But if there is any semi-official collection of typical
strings as "This message does not belong to me", I
definitely would prefer that ;-)


If something like this exists, I would be glad to hear about
that...

Thanks
Volker

Reg wrote:

Hi Reg,

thanks for your response.

Well, I have done some testing - unfortunately not very
systematically - , and I had the impression that the
behaviour was not absolutely as with 8.0.1.
So I will have to work further on that.

One further question: Is there any documentation on what
type of messages SQL Remote will generate?
In order to analyse possible problems, I have tried to
collect especially the messages that hint at such problems.
I have extracted them from SQL Remote logs.
But if there is any semi-official collection of typical
strings as "This message does not belong to me", I
definitely would prefer that ;-)


If something like this exists, I would be glad to hear about
that...

Thanks
Volker

Reg wrote:

The closest thing you'll find to a list of documented SQL Remote error
messages is here :

http://www.sybase.com/detail?id=1012485

The problem with trying to document all the possible SQL Remote messages is
that a lot of the errors are simply printing the error returned from the OS
when errors occur in the messaging system. The list in the link is pretty
complete as far as non-OS related SQL Remote error messages go.

--
Reg Domaratzki, Sybase iAnywhere Solutions
Sybase Certified Professional - Sybase ASA Developer Version 8
Please reply only to the newsgroup

iAnywhere Developer Community : http://www.ianywhere.com/developer
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
ASA Patches and EBFs : http://downloads.sybase.com/swd/base.do
-> Choose SQL Anywhere Studio
-> Set filter to "Display ALL platforms IN ALL MONTHS"


<Volker Barth> wrote

Hi Reg,

this document is one of the sources of my internal
collection of error messages (and very useful for their
explanation, too!).

So it looks like I should be prepared to analyse most of the
possible errors and warnings ;-)

Thanks again for your hint!

Volker


Reg wrote:

Hi Reg,

just for the record:

After some testing I have found out that using the
DBTools-API with DB_TOOLS_VERSION_NUMBER = 8_0_00 against a
8.0.3 database is not fully compatible with running against
a 8.0.1 database:

There are a few messages that show up as errors under 8.0.1
and are treated as warnings under 8.0.3, e.g.:
Not applying operations that have already...
Not applying operations with old resend count...
Deleting corrupt message...
This list doesn't claim to be complete.

So these messages will be handled via the new "warningrtn"
callback under DB_TOOLS_VERSION_NUMBER =
DB_TOOLS_VERSION_8_0_3.

In contrast, running on the same 8.0.3 database with
DB_TOOLS_VERSION_NUMBER = DB_TOOLS_VERSION_8_0_00, they will
be handled via the "msgrtn" callback whereas against a 8.0.1
database they are handled via the "errorrtn" callback.

So, in my case, I will recompile my application against the
8.0.3 DBTools-API in order to get them analyzed correctly.

Volker