Mobilink Sync Model deployment and non-sync-related objects

[HUnterholzer]

I am using SQLAnywhere 17 Mobilink plugin in SQL Central, deploying a Synchronization model with the Wizard. Deploying a new remote database, it creates all involved tables, publications, subscriptions and ML user. But not the foreign key constraints that exist in the consolidated database for these tables.

Forgive me the silly question, but do I have to create the FKs and all other non-synchronization related objects for that matter in this ‘new’ remote database separately?

[Breck_Carter]

I think so... but who am I to say?

Caveat Emptor: I've been setting up MobiLink syncs since forever, but I've never used the Wizard, er, model all the way through to production on anything.

So take this with a grain of salt...

I took another look using ML V17 yesterday, on a parent and two child tables selected from an SA V17 database, and it LOOKS LIKE it only creates the most basic of schema subsets (table and column names and data types, primary key and NULL and DEFAULT constraints and... um... that's it... not even a lowly column CHECK constraint 🙂

What you GET for your money is all . . . those . . . millions . . . of . . . basic . . . event scripts generated for you. That might be worth something to you, at least in terms of terminally . . . boring . . . code.

If your MobiLink setup is simple, then that might be all you need... but if your setup is THAT simple maybe you should consider SQL Remote (which is NOT dead, big ships run on it, all over the world's oceans).

You might be able to leverage the Wizard, but don't pin too many hopes and dreams on it: You won't be able to reverse post-Wizard customizations back into the model. You won't be able to manage or maintain or debug synchronization without actually understanding how the event scripts work.

Personally, I am surprised at how little the Wizard has changed over the years... MobiLink has moved onwards but the Wizard is still living at home in it's mother's basement 🙂

What's the alternative? One possibility is use the Wizard to generate as close as you can get to what you need, then capture the scripts in text files and treat them like source code, and throw away the Wizard. You have to take control and responsibility for every ... single ... aspect of synchronization. After all, you are now dealing with a distributed database... yes, you are... even if you didn't pay attention in that course 🙂