cancel
Showing results for 
Search instead for 
Did you mean: 

ML_GET_BLOCKED_INFO

GHellem
Discoverer
0 Kudos
357

SQL Anywhere 17 MobiLink comm server sync error: We randomly see this error when we setup a new user and sometimes with existing users, we get this error during sync and it takes several minutes to drop the failed sync.

<Main> [-10002] Consolidated database server or ODBC error:  ODBC: [SAP][SQL Anywhere - Oracle][Oracle]ORA-06553: PLS-306: wrong number or types of arguments in call to 'ML_GET_BLOCKED_INFO'

This appears internal to MobiLink code.  We are currently upgrading from Sybase 9 to SQL Anywhere 17 if this somehow resulted in the error as the parameters to ML_GET_BLOCKED_INFO are different between the two versions.  This doesn't explain how it works most of the time and fails some of the time though.

The error repeats until manual intervention is taken.  It appears that restarting the database and Mobilink service(s) clears the error, but this is not an acceptable fix in our client's production systems.  We see the error on two users yesterday and restarting the database and rebooting the comm server does not clear the error on both users.

regdomaratzki
Product and Topic Expert
Product and Topic Expert
0 Kudos
When you upgraded the version of the MobiLink Server you were using, did you also run the upgrade script in $SQLANY17/MobiLink/upgrade/9.0.[0|1|2]/upgrade_ora.sql file against your consolidated database?
regdomaratzki
Product and Topic Expert
Product and Topic Expert
0 Kudos

> This doesn't explain how it works most of the time and fails some of the time though.
This stored procedure is only called when the MobiLink Server is unable to get a lock on a row in the ml_database table at the start of the synchronization. 
This can occur when remote database "X" attempts to synchronize, but the MobiLink server is already processing a synchronization from remote database "X".  

GHellem
Discoverer
0 Kudos
I guess I need to provide more background on this issue... Originally, our client database was being used to synchronize handhelds uaing Sybase 9.0 for our FAST schema. When we upgraded to SQL Anywhere 17 we created a new schema named FAST_UL, in the same database. We only ran syncora.sql under the new FAST_UL schema and nothing else. We've set it up this way as our clients need to sync with Sybase 9 and 17. There are two different Mobilink services with each using a different user/schema. One uses FAST while the other uses FAST_UL. We haven't had any problems with this configuration at our client sites, well we do gat a few ML_GET_BLOCKED_INFO errors every now and then but they seem to resolve themselves. All of our development configurations use our Azure VM using an Amazon hosted database. We have other test clients set up the same way for development purposes, but only one is causing us major headaches with getting this error constantly. We have compared databases, Mobilink services, ODBC connections, etc., and they are all the same (but with different databases of course). The ODBC DSN and Mobilink service are set up to use FAST_UL when using Sybase 17. Again, we did not run upgrade_ora.sql as my colleague thinks that running syncora.sql is sufficient. He's also worried about other tables being affected, like ml_user, but I'm not sure why he cares. Should we go ahead and run upgrade_ora.sql under our FAST_UL schema? Would we need to run syncora.sql again after that? Also re-compiling the ML_GET_BLOCKED_INFO did not resolve the problem.
regdomaratzki
Product and Topic Expert
Product and Topic Expert
0 Kudos

I understand your environment better now, thank you.  I hadn't recognized that you had both the v9 MobiLink system table defined on one schema, and the v17 MobiLink system tables defined on a different schema.  There is no reason to run the upgrade_ora.sql file against the FAST_UL schema where you have already run the v17 syncora.sql file in that schema,

Can you please post the connection string that the v17 MobiLink Server uses when connecting to Oracle server, as well as the contents of the DSN that you are using in the connection string?  Please remember to XXXX-out any passwords.

Thanks,
Reg

Accepted Solutions (0)

Answers (2)

Answers (2)

GHellem
Discoverer
0 Kudos

The ML_GET_BLOCKED_INFO error indicates "wrong number or types of arguments in call to 'ML_GET_BLOCKED_INFO'" so what would be calling it with the wrong number of parameters? Under our Sybase 9 schema (FAST) there is no ML_GET_BLOCKED_INFO but I could've sworn I saw one with only two parameters whereas the Sybase 17 version has two paramters.

Just curoius as to what's up with the wrong number of parameters, as well as everything else.

Thanks

GHellem
Discoverer
0 Kudos
I meant that the Sybase 17 uses three parameters, not two.
jeff_albion
Advisor
Advisor
0 Kudos

It sounds possible that after the upgrade, the procedure definition is out of date and some active database connections are still using the old procedure definition until they are restarted. Have you tried running a recompile on the procedure in Oracle instead of restarting the entire database to see if that helps?

 

ALTER PROCEDURE ML_GET_BLOCKED_INFO COMPILE;