SQL Anywhere Mobile - Getting -10050 error and server crash with Oracle plus the solution

Author

Getting -10050 error and server crash with Oracle plus the solution

Paul Watje

2005-11-17, 11:24 am

This is an FYI

I am running Mobilink 9.0.1 Build 1751 against Oracle 9i, but upgrading the
server did not solve this error.

For all other customers things worked well, but for one customer the
Mobilink server started getting a -10050 error and then the server would
crash. But we could not get the server to error consistantly.

We finally figured out that the server would work fine for the first sync to
a PDA 1 logging in as user A and then we would sync a second PDA 2 as user B
and a particular stored procedure would throw an error and the server would
crash.,. If we reset the PDA's and reverse the PDA order, sync on PDA 2 as
user B first, then sync on PDA 1 as user 1, the second sync that would crash
the server when executing the procedure. It was always the second sync that
caused the problem. So we knew that the -10050 error, number of parameters
does not match, was not correct, since the store procedure would execute
properly in certain cases.

The procedure that was the server was crashing on had eight different
cursors that based on the user setup, changed the dataset downloaded to the
PDA. If the first sync used curser 1, and the second sync used cursor 1,
things worked properly. But if the first sync used cursor 1 and the second
sync used a different cursor, the stored procedure would throw an
error -10050, Mobilink would catch the error, close everyting down, and then
crash. If you added a close cursor to the stored procedure, there server
would not crash, but you got a -10050 error everytime. No help there. So I
forced the stored procedure to use only one cursor, and everything worked
fine. So I took a guess that the mulitple cursors was the issue. I created
a working table, replaced the cursors with inserts, that inserted the
appropriated dataset into the working table, and then create the cursor on
the working table to download the data. And everything worked properly.
Added the delete prior data for the current user logic, and everybody was a
happy camper.

Hope this helps somebody.

Paul Watje

Reg Domaratzki $iAnywhere Solutions$

2005-11-17, 1:24 pm

Do I understand from your post that you have different remote database with
different schemas all using the script version, but different result sets
are returned from the download_cursor event?

This is not the right way to do things. If you have remotes with different
schemas, you should have a different script version defined for each of the
different schema. The problem you were running into was because MobiLink
assumes that the input and parameters and result set for each of the
MobiLink events will always be the same in a given script version, so we
cache the data structures to store the result sets ( and input parameters ).
When user A synchronized with schema X (using script version 'v1'), MobiLink
will have cached database structures for the result set returned from the
download_cursor event. Next, user B synchronizes with schema Y, and because
it is also using script version 'v1', it will attempt to stuff the result
from the download cursor into the same data structures, which will fail
miserably.

You should be using different script versions for different schemas, but if
you want to try and put a round peg into a square hole, using the "-ps 0"
switch on the MobiLink server may have helped, since that will prevent
MobiLink from caching any prepared statements.

--
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/swx/sdmain.stm
-> Choose SQL Anywhere Studio
-> Set filter to "Display ALL platforms IN ALL MONTHS"

"Paul Watje" <paulwatje@hotmail.com> wrote in message
news:437cae6c$1@foru
ms-1-dub...
> This is an FYI
>
> I am running Mobilink 9.0.1 Build 1751 against Oracle 9i, but upgrading
the
> server did not solve this error.
>
> For all other customers things worked well, but for one customer the
> Mobilink server started getting a -10050 error and then the server would
> crash. But we could not get the server to error consistantly.
>
> We finally figured out that the server would work fine for the first sync
to
> a PDA 1 logging in as user A and then we would sync a second PDA 2 as user
B
> and a particular stored procedure would throw an error and the server
would

> crash.,. If we reset the PDA's and reverse the PDA order, sync on PDA 2
as
> user B first, then sync on PDA 1 as user 1, the second sync that would
crash

> the server when executing the procedure. It was always the second sync
that
> caused the problem. So we knew that the -10050 error, number of
parameters
> does not match, was not correct, since the store procedure would execute
> properly in certain cases.
>
> The procedure that was the server was crashing on had eight different
> cursors that based on the user setup, changed the dataset downloaded to
the
> PDA. If the first sync used curser 1, and the second sync used cursor 1,
> things worked properly. But if the first sync used cursor 1 and the
second
> sync used a different cursor, the stored procedure would throw an
> error -10050, Mobilink would catch the error, close everyting down, and
then
> crash. If you added a close cursor to the stored procedure, there server
> would not crash, but you got a -10050 error everytime. No help there. So
I
> forced the stored procedure to use only one cursor, and everything worked
> fine. So I took a guess that the mulitple cursors was the issue. I
created
> a working table, replaced the cursors with inserts, that inserted the
> appropriated dataset into the working table, and then create the cursor on
> the working table to download the data. And everything worked properly.
> Added the delete prior data for the current user logic, and everybody was
a
> happy camper.
>
> Hope this helps somebody.
>
> Paul Watje
>
>
>
>
>
>

Sponsored Links