Skip to Content

Archived discussions are read-only. Learn more about SAP Q&A

Column order in Mobilink 16

Hello, all

Several of my clients reported a problem that mobilink does not send data correctly from their client DBs to the consolidated DB.

When I examined their DBs I noticed that the problematic table had different column order for some reason. This caused the Mobilink update incorrect fields.

My question - is there a way to tell the Mobilink to use column names instead of numbers? The update script is correct, however, it is useless, because it is updating according to the column ID, instead of the column name.

What can be done about it, short of destroying the table and recreating it?

replied

It was the use of Sybase Central and Synchronization Models that was the source of the problem here.

When you create a synchronization model, the MobiLink Plug-in continues to use the ml_add_column stored procedure defined in the ML System tables to explicitly define the order of the columns as they are defined in remote database.  These calls are no longer needed in current software (we always send column names now), and if fact, the ml_add_column stored procedure has been deprecated in version 16.  They calls typically don't cause any problems unless the order of the columns at the remote databases differ from remote to remote.  When the column orders are different, this corrupts data on download, but you were doing upload only synchs, so that wouldn't happen.

You can get around your issue by deleting all the rows in the ml_column MobiLink System table in your consolidated database.    You may need to do this every time you re-deploy

If there is any fix to be made, it is with the MobiLink Plug-in in Sybase Central.  It should likely no longer be using a deprecated stored procedure when it is no longer needed, although yours is the first environment ever where it has been an issue.  I will discuss with the tools teams as to whether a fix is needed, but my guess is that no fix will be made to the plugin, since remote databases using the same synchronization script version should have the same schema.  It is only because you are not downloading data that you are not having more serious issues.

Please keep in mind that if you ever decide you want to download data to the remote databases, this environment you have with different ordering of columns from remote to remote is GUARANTEED to cause data integrity issues. 

Reg Domaratzki

1 View this answer in context

Helpful Answer

by
Not what you were looking for? View more on this topic or Ask a question