0
SQL924: Migrating Your SQL Remote Environment to Mobilink Reg Domaratzki Sustaining Engineering [email_address] August 15-...
<ul><li>Assumptions </li></ul><ul><li>MobiLink Overview </li></ul><ul><li>Why Migrate? </li></ul><ul><li>Changes on the Re...
My Foot <ul><li>I turned my ankle, and the muscle that connects the fifth metatarsal (bone 12) to the cuboid (bone 7) was ...
Assumptions <ul><li>Working knowledge of SQL Remote, but not necessarily MobiLink </li></ul><ul><li>SQL Remote concepts I’...
The Enterprise. Unwired.
The Enterprise. Unwired. Unwire People Unwire Information Manage Information Sybase Workspace Industry and Cross Platform ...
MobiLink Overview
MobiLink Overview <ul><li>Scripts define actions performed at the consolidated database at each stage or  event  during sy...
MobiLink Overview <ul><li>Scripts are either connection level scripts or table level scripts </li></ul><ul><ul><li>Events ...
MobiLink Overview <ul><li>No message system, direct connection to MobiLink, which is connected to the consolidated databas...
<ul><li>Assumptions </li></ul><ul><li>MobiLink Overview </li></ul><ul><li>Why Migrate? </li></ul><ul><li>Changes on the Re...
Why Migrate? <ul><li>There is NO need to migrate a system that is in production and meets all your business needs </li></u...
Why Migrate? <ul><li>Sybase and iAnywhere Solutions provides three different technologies that allow you to move data from...
Why Migrate? <ul><li>With the upcoming Jasper release of SQL Anywhere Studio, iAnywhere Solutions has decided to announce ...
Migration Goals <ul><li>Little or no impact on end users </li></ul><ul><ul><li>Remote users should not know that anything ...
<ul><li>Assumptions </li></ul><ul><li>MobiLink Overview </li></ul><ul><li>Why Migrate? </li></ul><ul><li>Changes on the Re...
Migration Strategies for Remote Users <ul><li>There should be no need to deploy a new database to the remote user when the...
Differences on the Remote <ul><li>Both SQL Remote and ASA MobiLink clients make use of a publication to determine which da...
Differences on the Remote <ul><li>Message system parameters are defined on the remote database so that SQL Remote knows wh...
Differences on the Remote <ul><li>SQL Remote : </li></ul><ul><li>CREATE PUBLICATION p1 ( TABLE t1 ); </li></ul><ul><li>GRA...
Differences on the Remote <ul><li>ASA MobiLink Client </li></ul><ul><li>CREATE PUBLICATION p1 ( TABLE t1 ); </li></ul><ul>...
Migration Steps on the Remote <ul><li>Run dbremote on the remote to send any outstanding changes to the consolidated datab...
Possible Problems <ul><li>If the last messages that are sent by the SQL Remote are lost, the guaranteed message delivery s...
Possible Problems <ul><li>It’s possible that between running dbremote to receive your final messages and before your first...
Possible Problems <ul><li>Those who were paying attention may have noticed that I presented two possible problems, and the...
Changes to the Remote Application <ul><li>Depending on how you were running dbremote on the remote clients, you may need t...
Changes to the Remote Application <ul><li>If you are making changes to your application, you should note that the DBMLSync...
<ul><li>Assumptions </li></ul><ul><li>MobiLink Overview </li></ul><ul><li>Why Migrate? </li></ul><ul><li>Changes on the Re...
Setting Up the Consolidated for MobiLink <ul><li>In the %ASANY%MobiLinksetup directory, a file named syncase125.sql exists...
Setting Up the Consolidated for MobiLink <ul><li>You should create a DSN that will be used by MobiLink to connect to the c...
Generating Compatible Upload Scripts <ul><li>With SQL Remote, the messages that are generated include actual SQL statement...
Example Schema <ul><li>Assume the following table structure exists at both the remote and the consolidated </li></ul><ul><...
Example Upload Scripts <ul><li>The data that is passed up in the upload stream will be passed to the upload scripts as par...
Defining Your Synchronization Scripts <ul><li>Synchronization scripts can either be defined using Sybase Central, or by ex...
Generating Compatible Download Scripts <ul><li>Your download scripts determine what data to send down to the remote users ...
Filtering Out Previously Downloaded Rows <ul><li>There are two other pieces of information that are included in the upload...
Filtering Out Previously Downloaded Rows <ul><li>You need to add a last_modified column of type datetime to each synchroni...
Filtering out Previously Downloaded Rows <ul><li>You’ll also need to add a update trigger to the table to ensure that the ...
Filtering out Previously Downloaded Rows <ul><li>You can now re-write your download_cursor to only download rows since the...
Filtering Out Previously Downloaded Rows <ul><li>It’s important to note that the last_modified column ONLY exists at the c...
Filtering Out Previously Downloaded Rows  <ul><li>In some situations, you cannot modify the base table because of the way ...
Filtering Out Previously Downloaded Rows <ul><li>Three triggers would need to be defined to track changes on the base tabl...
Filtering Out Previously Downloaded Rows <ul><li>When using shadow tables, the download_cursor would now have to join two ...
Partitioning Rows by Remote User <ul><li>With SQL Remote, on the consolidated database, you could partition rows by remote...
Partitioning Rows by Remote User <ul><li>With MobiLink, because the name of the MobiLink user is passed up in the upload s...
Downloading Deletes <ul><li>Since MobiLink does not scan the transaction log of the consolidated database, and since downl...
Downloading Deletes <ul><li>Using the same table t2 from the previous slides, we’d create a table called t2_del </li></ul>...
Downloading Deletes <ul><li>We would also define a delete trigger on t2 that inserted a row into t2_del each time a row wa...
Downloading Deletes <ul><li>This now allows us to define our download_delete_cursor for table t2 </li></ul><ul><ul><li>exe...
Territory Re-alignment <ul><li>Territory re-alignment for SQL Remote for ASE is done by maintaining another subscribe by c...
Generating Conflict Resolution Scripts <ul><li>To define conflict resolution scripts for SQL Remote for ASE, when adding t...
Generating Compatible Conflict Resolution Scripts <ul><li>The three events that fire are incredibly similar to the algorit...
First Synchronization From Migrated Remote <ul><li>When we discussed migrating the remote databases, we glossed over some ...
First Synchronization From Migrated Remote <ul><li>We’ll define a modify_last_download_timestamp event that will do the fo...
First Synch From New MobiLink Client <ul><li>The initial synchronization from a new MobiLink client will have a last_downl...
First Synch From New MobiLink Client <ul><li>Because the initial values of the new last_modified columns were set to ‘1900...
Migrating from SSRemote to MobiLink <ul><li>With years of experience iAnywhere Professional Services can deliver tailored ...
<ul><li>Ask the iAnywhere Experts on the Technology Boardwalk (exhibit hall) </li></ul><ul><ul><li>Drop in during exhibit ...
iAnywhere at TechWave2004 <ul><li>Wi-Fi Hotspots – brought to you by Intel  </li></ul><ul><ul><li>You can enjoy wireless i...
Upcoming SlideShare
Loading in...5
×

Migrating Your SQL Remote Environment to Mobilink

1,070

Published on

1 Comment
0 Likes
Statistics
Notes
  • This is excellent presentation, please check this site for on site database work http://dbawork.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total Views
1,070
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide
  • The Unwired Enterprise is an information management strategy. In this session, we’ll be discussing this (POINT OUT YOUR PRODUCT OR SOLUTION AREA) section of Sybase’s Unwired Enterprise solution.
  • Transcript of "Migrating Your SQL Remote Environment to Mobilink"

    1. 1. SQL924: Migrating Your SQL Remote Environment to Mobilink Reg Domaratzki Sustaining Engineering [email_address] August 15-19, 2004
    2. 2. <ul><li>Assumptions </li></ul><ul><li>MobiLink Overview </li></ul><ul><li>Why Migrate? </li></ul><ul><li>Changes on the Remote </li></ul><ul><li>Changes at the Consolidated Database </li></ul>Outline
    3. 3. My Foot <ul><li>I turned my ankle, and the muscle that connects the fifth metatarsal (bone 12) to the cuboid (bone 7) was stronger than the bone </li></ul><ul><li>The fifth metatarsal broke just above the connection to the cuboid </li></ul><ul><li>Yes, it hurts </li></ul>
    4. 4. Assumptions <ul><li>Working knowledge of SQL Remote, but not necessarily MobiLink </li></ul><ul><li>SQL Remote concepts I’ll assume you understand </li></ul><ul><ul><li>Consolidated versus Remote Database </li></ul></ul><ul><ul><li>Publications, remote users and subscriptions </li></ul></ul><ul><ul><li>Subscribe by Columns </li></ul></ul><ul><ul><li>Default Conflict Resolution </li></ul></ul><ul><li>This talks deals primarily with migrating SQL Remote for ASE to using MobiLink with an ASE Consolidated Database </li></ul><ul><li>dbremote, ssremote and SQL Remote </li></ul>
    5. 5. The Enterprise. Unwired.
    6. 6. The Enterprise. Unwired. Unwire People Unwire Information Manage Information Sybase Workspace Industry and Cross Platform Solutions <ul><li>Adaptive Server Enterprise </li></ul><ul><li>Adaptive Server Anywhere </li></ul><ul><li>Sybase IQ </li></ul><ul><li>Dynamic Archive </li></ul><ul><li>Dynamic ODS </li></ul><ul><li>Replication Server </li></ul><ul><li>OpenSwitch </li></ul><ul><li>Mirror Activator </li></ul><ul><li>PowerDesigner </li></ul><ul><li>Connectivity Options </li></ul><ul><li>EAServer </li></ul><ul><li>Industry Warehouse Studio </li></ul><ul><li>Unwired Accelerator </li></ul><ul><li>Unwired Orchestrator </li></ul><ul><li>Unwired Toolkit </li></ul><ul><li>Enterprise Portal </li></ul><ul><li>Real Time Data Services </li></ul><ul><li>SQL Anywhere Studio </li></ul><ul><li>M-Business Anywhere </li></ul><ul><li>Pylon Family (Mobile Email) </li></ul><ul><li>Mobile Sales </li></ul><ul><li>XcelleNet Frontline Solutions </li></ul><ul><li>PocketBuilder </li></ul><ul><li>PowerBuilder Family </li></ul><ul><li>AvantGo </li></ul>
    7. 7. MobiLink Overview
    8. 8. MobiLink Overview <ul><li>Scripts define actions performed at the consolidated database at each stage or event during synchronization </li></ul><ul><ul><li>begin_connection </li></ul></ul><ul><ul><li>for each synchronization: </li></ul></ul><ul><ul><ul><li>begin_synchronization </li></ul></ul></ul><ul><ul><ul><li>receive and apply upload stream </li></ul></ul></ul><ul><ul><ul><li>prepare and send download stream </li></ul></ul></ul><ul><ul><ul><li>end_synchronization </li></ul></ul></ul><ul><ul><li>end_connection </li></ul></ul>
    9. 9. MobiLink Overview <ul><li>Scripts are either connection level scripts or table level scripts </li></ul><ul><ul><li>Events occur for each synchronization, and events occur for each table that is being synchronized </li></ul></ul><ul><ul><li>The scripts determine how data is proceeded in the upload stream and what data gathered to be placed in the download stream </li></ul></ul>
    10. 10. MobiLink Overview <ul><li>No message system, direct connection to MobiLink, which is connected to the consolidated database using ODBC </li></ul><ul><ul><li>The connection can use a variety of different communication streams including TCP/IP, HTTP, HTTPS, Serial, HotSync or ActiveSync </li></ul></ul><ul><ul><li>The remote sends changes up the consolidated and receives changes from the consolidated in the same synchronization session </li></ul></ul><ul><li>You define synchronization scripts that define how MobiLink will handle the data that is uploaded by the remote database, and what data needs to be downloaded to the remote database </li></ul><ul><ul><li>MobiLink does NOT scan the log file on the consolidated database </li></ul></ul><ul><ul><li>The ASA MobiLink client at the remote database (dbmlsync.exe) does scan the remote log file to determine what data to send to the consolidated database </li></ul></ul><ul><ul><li>The download script you write for a given table returns a result set. It is this result set that is sent down to the remote </li></ul></ul>
    11. 11. <ul><li>Assumptions </li></ul><ul><li>MobiLink Overview </li></ul><ul><li>Why Migrate? </li></ul><ul><li>Changes on the Remote </li></ul><ul><li>Changes at the Consolidated Database </li></ul>Outline
    12. 12. Why Migrate? <ul><li>There is NO need to migrate a system that is in production and meets all your business needs </li></ul><ul><ul><li>If it isn’t broken, there’s no need to fix it </li></ul></ul><ul><li>There are many things that MobiLink can offer that SQL Remote does not </li></ul><ul><ul><li>Any ODBC-Compliant consolidated database </li></ul></ul><ul><ul><ul><li>The currently supported consolidated database are ASA, ASE, MS SQL Server, Oracle and DB2 </li></ul></ul></ul><ul><ul><li>Can synchronize to an UltraLite application </li></ul></ul><ul><ul><li>More flexibility during upload and download of data </li></ul></ul><ul><ul><li>Less data latency in a MobiLink environment </li></ul></ul><ul><ul><li>Ability to easily encrypt the communication between remote and consolidated databases using 128-bit encryption </li></ul></ul><ul><ul><li>Server Initiated Synchronization </li></ul></ul>
    13. 13. Why Migrate? <ul><li>Sybase and iAnywhere Solutions provides three different technologies that allow you to move data from an ASE database to an ASA database </li></ul><ul><ul><li>Replication Server : Connection Based </li></ul></ul><ul><ul><li>MobiLink : Session Based </li></ul></ul><ul><ul><li>SQL Remote for ASE : Message Based </li></ul></ul><ul><li>For high-speed two-way replication between always connected databases with low latency demands, Replication Server is the obvious choice </li></ul><ul><li>In the disconnect environment, MobiLink and SQL Remote for ASE share a very similar solution space </li></ul>
    14. 14. Why Migrate? <ul><li>With the upcoming Jasper release of SQL Anywhere Studio, iAnywhere Solutions has decided to announce the end of life for SQL Remote for ASE </li></ul><ul><ul><li>The migration path for current SQL Remote for ASE users is to use MobiLink instead of SQL Remote for ASE </li></ul></ul><ul><ul><li>For the few people using SQL Remote for ASE to replicate between two ASE databases, the migration path is to use the new SQL Replicator that shipped with ASE v12.5.1 </li></ul></ul><ul><li>Please note that the end of life notification for SQL Remote for ASE in no way affects the status of SQL Remote for ASA </li></ul><ul><ul><li>SQL Remote replication between ASA databases continues to be a strong and viable product in SQL Anywhere Studio package </li></ul></ul>
    15. 15. Migration Goals <ul><li>Little or no impact on end users </li></ul><ul><ul><li>Remote users should not know that anything has changed </li></ul></ul><ul><ul><li>No training costs associated with migration for end users </li></ul></ul><ul><li>Gradual migration </li></ul><ul><ul><li>Avoid a situation where current users cannot access new data until they upgrade </li></ul></ul><ul><ul><li>It is unreasonable to think that everyone will upgrade at the same point </li></ul></ul><ul><li>No lose of current functionality </li></ul><ul><ul><li>A migration path that limits functionality is not acceptable </li></ul></ul><ul><ul><li>The new system should be able to do everything the old system could, and hopefully more </li></ul></ul>
    16. 16. <ul><li>Assumptions </li></ul><ul><li>MobiLink Overview </li></ul><ul><li>Why Migrate? </li></ul><ul><li>Changes on the Remote </li></ul><ul><ul><li>Migration Strategies for Remote Users </li></ul></ul><ul><ul><li>Differences on the Remote </li></ul></ul><ul><ul><li>Migration Steps on the Remote </li></ul></ul><ul><ul><li>Changes to the Remote Application </li></ul></ul><ul><li>Changes at the Consolidated Database </li></ul>Outline
    17. 17. Migration Strategies for Remote Users <ul><li>There should be no need to deploy a new database to the remote user when the switch is made from using SQL Remote to MobiLink </li></ul><ul><li>It is possible that new ASA software may need to be deployed if the dbmlsync.exe executable does not already exist on the remote database </li></ul><ul><ul><li>As soon as you start talking about sending new software to the remote users, you may also want to consider whether you want to take this opportunity to upgrade to a more recent version of ASA </li></ul></ul><ul><ul><li>The only new ASA files that need to be deployed are dbmlsync.exe and the associated stream DLL (i.e. dbmlsock9.dll or dbmlhttp9.dll) </li></ul></ul>
    18. 18. Differences on the Remote <ul><li>Both SQL Remote and ASA MobiLink clients make use of a publication to determine which data needs to be sent to the consolidated database </li></ul><ul><ul><li>The same publication that you defined for SQL Remote at the remote database can also be used for ASA MobiLink Clients </li></ul></ul><ul><li>SQL Remote clients define a consolidated user on the remote database, and subscribes the consolidated user to a publication </li></ul><ul><ul><li>An ASA MobiLink client defines a Synchronization User and you define a Synchronization Subscription to link a Synchronization User to a Publication </li></ul></ul>
    19. 19. Differences on the Remote <ul><li>Message system parameters are defined on the remote database so that SQL Remote knows where and how messages are written to shared message system </li></ul><ul><ul><li>An ASA MobiLink client connects directly to the MobiLink server, so instead of specifying the location of the message system, you specify the communication stream type you are using and the location of the MobiLink server </li></ul></ul><ul><ul><li>This can be done when defining either the Synchronization User or when defining the Synchronization Subscription </li></ul></ul>
    20. 20. Differences on the Remote <ul><li>SQL Remote : </li></ul><ul><li>CREATE PUBLICATION p1 ( TABLE t1 ); </li></ul><ul><li>GRANT PUBLISH to u1; </li></ul><ul><li>CREATE REMOTE MESSAGE TYPE ‘file’ ADDRESS ‘u1’; </li></ul><ul><li>GRANT CONSOLIDATED TO cons TYPE file ADDRESS ‘cons’; </li></ul><ul><li>CREATE SUBSCRIPTION TO cons FOR p1; </li></ul><ul><li>SET REMOTE file OPTION </li></ul><ul><li>“ public”.”root_directory” = ‘r:sgs’; </li></ul>
    21. 21. Differences on the Remote <ul><li>ASA MobiLink Client </li></ul><ul><li>CREATE PUBLICATION p1 ( TABLE t1 ); </li></ul><ul><li>CREATE SYNCHRONIZATION USER u1; </li></ul><ul><li>CREATE SYNCHRONIZATION SUBSCRIPTION </li></ul><ul><li>FOR u1 TO p1 TYPE ‘TCPIP’ </li></ul><ul><li>ADDRESS ‘host=10.2.3.1;port=600’ </li></ul><ul><li>OPTION ‘sv=v1’; </li></ul>
    22. 22. Migration Steps on the Remote <ul><li>Run dbremote on the remote to send any outstanding changes to the consolidated database </li></ul><ul><ul><li>This will also pick up any changes already sent from the consolidated and apply them to the remote database </li></ul></ul><ul><li>Drop the consolidated user </li></ul><ul><ul><li>No more SQL Remote messages can now be received or applied by this remote </li></ul></ul><ul><li>Create a new Synchronization User and Subscription </li></ul><ul><ul><li>All new changes made on the remote database will now be synchronized using MobiLink instead of SQL Remote </li></ul></ul><ul><ul><li>Use the CURRENT PUBLISHER of the remote database for the name of the Synchronization User </li></ul></ul><ul><li>Run dbmlsync and perform your first synchronization </li></ul>
    23. 23. Possible Problems <ul><li>If the last messages that are sent by the SQL Remote are lost, the guaranteed message delivery system can no longer be used, since the consolidated user was dropped </li></ul><ul><ul><li>To get around this, you could choose only to drop the consolidated user if the log_sent value in the SYS.SYSREMOTEUSER table for the consolidated user was equal to the confirmed_received value </li></ul></ul><ul><ul><ul><li>You could run dbremote in receive only mode after sending message and before dropping your consolidated user until log_sent was equal to confirmed_received </li></ul></ul></ul><ul><ul><ul><li>Only a viable option if the send frequency on the consolidated is short </li></ul></ul></ul><ul><ul><li>This would guarantee that all messages sent had been received and applied on the consolidated database </li></ul></ul>
    24. 24. Possible Problems <ul><li>It’s possible that between running dbremote to receive your final messages and before your first dbmlsync run, that SQL Remote on the consolidated could generate a message for the remote, which would never be applied </li></ul><ul><ul><li>This entire process will likely be automated in a batch file, so the chance is slim, but not zero </li></ul></ul><ul><ul><li>The chances of this occurring would be higher if the SQL Remote send frequency on the consolidated database was very small </li></ul></ul><ul><ul><li>Those paranoid about this could increase the send frequency on the consolidated to one hour, which would almost completely eliminate the chance of the problem occurring </li></ul></ul>
    25. 25. Possible Problems <ul><li>Those who were paying attention may have noticed that I presented two possible problems, and the solution to each problem was to increase or decrease the send frequency </li></ul><ul><ul><li>Obviously, both cannot be done </li></ul></ul><ul><li>The best way to guarantee that NO data is lost is to extract a new remote database for the user </li></ul><ul><ul><li>This talks attempts to give you an alternative, that has a small chance of data being lost, but with very little impact to end users and very low administration costs </li></ul></ul>
    26. 26. Changes to the Remote Application <ul><li>Depending on how you were running dbremote on the remote clients, you may need to change the application that ran dbremote to now run dbmlsync instead </li></ul><ul><ul><li>If dbremote were run as a service, and new service would have to be defined that ran dbmlsync instead of dbremote </li></ul></ul><ul><ul><li>If users clicked on a batch file, the batch file would need to be changed </li></ul></ul><ul><ul><li>If you were using the DBTOOLS API to call dbremote, you would need to change your code to now call DBSynchronizeLog(), and define a new structure to pass into DBSynchronizeLog() </li></ul></ul><ul><ul><li>If your application spawned an external process (I.e. dbremote) it would now spawn dbmlsync </li></ul></ul>
    27. 27. Changes to the Remote Application <ul><li>If you are making changes to your application, you should note that the DBMLSync Integration Component can be used to launch the synchronization process </li></ul><ul><ul><li>The DBMLSync Integration Component is an ActiveX plug-in that can be imported into Visual Basic, PowerBuilder, Delphi, or any other application development tool that can utilize an ActiveX component </li></ul></ul><ul><ul><ul><li>Note that there are third-party tools that allow you to import an ActiveX component into the .NET Compact Framework programming environment </li></ul></ul></ul><ul><ul><li>There is both a visual and non-visual version of the DBMLSync Integration Component </li></ul></ul><ul><ul><ul><li>The visual component will bring up a dialog box very similar to the dbmlsync executable and allows you to set the inputs to the component </li></ul></ul></ul><ul><ul><ul><li>The non-visual component requires you to do more programming work, but gives you access to much more customization, including access to every row being uploaded and downloaded during synchronization </li></ul></ul></ul>
    28. 28. <ul><li>Assumptions </li></ul><ul><li>MobiLink Overview </li></ul><ul><li>Why Migrate? </li></ul><ul><li>Changes on the Remote </li></ul><ul><li>Changes at the Consolidated Database </li></ul><ul><ul><li>Setting up the Consolidated Database </li></ul></ul><ul><ul><li>Generating Upload Scripts </li></ul></ul><ul><ul><li>Generating Download Scripts </li></ul></ul><ul><ul><li>Downloading Deletes </li></ul></ul><ul><ul><li>Territory Re-alignment </li></ul></ul><ul><ul><li>Conflict Resolution </li></ul></ul><ul><ul><li>First Synchronizations </li></ul></ul>Outline
    29. 29. Setting Up the Consolidated for MobiLink <ul><li>In the %ASANY%MobiLinksetup directory, a file named syncase125.sql exists that must be run against the consolidated database </li></ul><ul><ul><li>You should modify the script and add a “use db_name” command at the beginning to ensure the right database is modified </li></ul></ul><ul><ul><li>You should run this script connected as the same user that MobiLink will connect with </li></ul></ul><ul><ul><ul><li>This user will need select, insert, update, and delete permissions on all tables involved in synchronization </li></ul></ul></ul>
    30. 30. Setting Up the Consolidated for MobiLink <ul><li>You should create a DSN that will be used by MobiLink to connect to the consolidated database </li></ul><ul><ul><li>Not all ODBC drivers are created equal </li></ul></ul><ul><ul><li>Be sure to read over the Recommended ODBC Drivers for MobiLink web page at the iAnywhere Solutions web site before creating your DSN </li></ul></ul><ul><ul><li>http://www.ianywhere.com/developer/technotes/odbc_mobilink.html </li></ul></ul><ul><ul><li>The SQL Anywhere Studio install proceed will install iAnywhere branded DataDirect OBDC drivers for most supported consolidated databases </li></ul></ul><ul><ul><ul><li>These drivers are tested prior to release and we would almost always recommend using these drivers over any other ODBC driver </li></ul></ul></ul>
    31. 31. Generating Compatible Upload Scripts <ul><li>With SQL Remote, the messages that are generated include actual SQL statements that are applied to the consolidated database </li></ul><ul><ul><li>The upload stream that is generated by dbmlsync does not include SQL statements, but instead includes the data in rows that were modified, and the type of modification that was made (insert, update or delete) </li></ul></ul><ul><ul><li>You must define upload scripts that are used to determine what actions are taken for the data being passed up in the upload stream </li></ul></ul>
    32. 32. Example Schema <ul><li>Assume the following table structure exists at both the remote and the consolidated </li></ul><ul><li>CREATE TABLE t1 ( </li></ul><ul><li>PKEY INTEGER PRIMARY KEY, </li></ul><ul><li>C1 INTEGER, </li></ul><ul><li>C2 VARCHAR(100), </li></ul><ul><li>C3 NUMERIC(10,2) </li></ul><ul><li>) </li></ul><ul><li>go </li></ul>
    33. 33. Example Upload Scripts <ul><li>The data that is passed up in the upload stream will be passed to the upload scripts as parameters and are represented with ? in the scripts </li></ul><ul><ul><li>Upload_Insert Script : </li></ul></ul><ul><ul><ul><li>insert into t1 (pkey,c1,c2,c3) values ( ?, ?, ?, ? ); </li></ul></ul></ul><ul><ul><li>Upload_Update Script : </li></ul></ul><ul><ul><ul><li>update t1 set c1 = ?, c2 = ?, c3 = ? where pkey = ?; </li></ul></ul></ul><ul><ul><li>Upload_Delete Script : </li></ul></ul><ul><ul><ul><li>delete from t1 where pkey = ?; </li></ul></ul></ul><ul><li>There are ways to automatically generate default scripts, which are usually acceptable for upload scripts </li></ul>
    34. 34. Defining Your Synchronization Scripts <ul><li>Synchronization scripts can either be defined using Sybase Central, or by executing stored procedures created by the syncase125.sql setup script : </li></ul><ul><ul><li>exec ml_add_table_script ‘v1’, ‘t1’, ‘Upload_Insert’, ‘insert into t1 (pkey,c1,c2,c3) values ( ?, ?, ?, ? )‘ </li></ul></ul><ul><ul><li>go </li></ul></ul><ul><ul><li>exec ml_add_table_script ‘v1’, ‘t1’, ‘Upload_Update’, ‘update t1 set c1 = ?, c2 = ?, c3 = ? where pkey = ?’ </li></ul></ul><ul><ul><li>go </li></ul></ul><ul><ul><li>exec ml_add_table_script ‘v1’, ‘t1’, ‘Upload_Delete’, ‘delete from t1 where pkey = ?’ </li></ul></ul><ul><ul><li>go </li></ul></ul>
    35. 35. Generating Compatible Download Scripts <ul><li>Your download scripts determine what data to send down to the remote users </li></ul><ul><li>The simplest download script is simply a select statement that sends all rows down to every remote user </li></ul><ul><ul><li>select pkey,c1,c2,c3 from t1 </li></ul></ul><ul><ul><li>exec ml_add_table_script ‘v1’, ‘t1’, ‘download_cursor’, ‘select pkey,c1,c2,c3 from t1‘ </li></ul></ul><ul><ul><li>go </li></ul></ul><ul><li>The problem with the above download_cursor is that every row is sent to every remote user on each synchronization, not just rows that were modified since the last download </li></ul>
    36. 36. Filtering Out Previously Downloaded Rows <ul><li>There are two other pieces of information that are included in the upload stream in each synchronization request from the remote </li></ul><ul><ul><li>The last time the user successfully downloaded data </li></ul></ul><ul><ul><li>The name of the synchronization user </li></ul></ul><ul><li>You can use the last successful download time to ensure that only modified rows are sent down to the remote for each synchronization </li></ul>
    37. 37. Filtering Out Previously Downloaded Rows <ul><li>You need to add a last_modified column of type datetime to each synchronizing table so that rows aren’t downloaded each time </li></ul><ul><ul><li>Ensure that the column has a DEFAULT value, which is defined as the current time </li></ul></ul><ul><ul><li>ALTER TABLE t1 ADD last_modified datetime default getdate() </li></ul></ul><ul><ul><li>go </li></ul></ul><ul><li>You should set the initial value for this column as ‘1900-01-01 00:01:00’ for all rows </li></ul>
    38. 38. Filtering out Previously Downloaded Rows <ul><li>You’ll also need to add a update trigger to the table to ensure that the last_modified column is updated each time the row is modified </li></ul><ul><ul><li>CREATE TRIGGER au_t1 ON t1 FOR UPDATE </li></ul></ul><ul><ul><li>AS </li></ul></ul><ul><ul><li>BEGIN </li></ul></ul><ul><ul><li>UPDATE t1 </li></ul></ul><ul><ul><li>SET last_modified = getdate() </li></ul></ul><ul><ul><li>WHERE pkey IN ( SELECT pkey FROM inserted ) </li></ul></ul><ul><ul><li>END </li></ul></ul><ul><ul><li>go </li></ul></ul>
    39. 39. Filtering out Previously Downloaded Rows <ul><li>You can now re-write your download_cursor to only download rows since the last successful synchronization </li></ul><ul><ul><li>exec ml_add_table_script ‘v1’, ‘t1’, ‘download_cursor’, ‘select pkey,c1,c2,c3 from t1 where last_modified >= ?‘ </li></ul></ul><ul><ul><li>go </li></ul></ul>
    40. 40. Filtering Out Previously Downloaded Rows <ul><li>It’s important to note that the last_modified column ONLY exists at the consolidated, and is NOT synchronized down to the remote </li></ul><ul><li>The schema may have changed on the consolidated, but not on the remote </li></ul><ul><li>Also note that you may now need to modify the publication definition on the consolidated database for current SQL Remote users </li></ul><ul><ul><li>Since all columns are no longer being replicated, it’s now necessary to include the list of columns that are being replicated to SQL Remote users. </li></ul></ul>
    41. 41. Filtering Out Previously Downloaded Rows <ul><li>In some situations, you cannot modify the base table because of the way existing applications access the database </li></ul><ul><li>In this scenario, instead of modifying the base table, you can add a shadow table that stored the last download time </li></ul><ul><ul><li>CREATE TABLE t1_st ( </li></ul></ul><ul><ul><li>pkey integer primary key, </li></ul></ul><ul><ul><li>last_modified datetime default getdate() </li></ul></ul><ul><ul><li>) </li></ul></ul><ul><ul><li>go </li></ul></ul><ul><li>This table should be populated with rows and have last_modified values set to ‘1900-01-01 00:01:00’ </li></ul>
    42. 42. Filtering Out Previously Downloaded Rows <ul><li>Three triggers would need to be defined to track changes on the base table if you are using shadow tables </li></ul><ul><ul><li>create trigger ai_t1 on t1 for insert as </li></ul></ul><ul><ul><li>begin </li></ul></ul><ul><ul><li>insert into t1_st select pkey,getdate() from inserted </li></ul></ul><ul><ul><li>end </li></ul></ul><ul><ul><li>create trigger au_t1 on t1 for update as </li></ul></ul><ul><ul><li>begin </li></ul></ul><ul><ul><li>update t1_st set last_modified = getdate() </li></ul></ul><ul><ul><li>where pkey in ( select pkey from inserted ) </li></ul></ul><ul><ul><li>end </li></ul></ul><ul><ul><li>create trigger ad_t1 on t1 for delete as </li></ul></ul><ul><ul><li>begin </li></ul></ul><ul><ul><li>delete from t1_st where pkey in ( select pkey from deleted ) </li></ul></ul><ul><ul><li>end </li></ul></ul><ul><ul><li>go </li></ul></ul>
    43. 43. Filtering Out Previously Downloaded Rows <ul><li>When using shadow tables, the download_cursor would now have to join two tables to filter out rows that have been previously downloaded </li></ul><ul><ul><li>exec ml_add_table_script ‘v1’, ‘t1’, ‘download_cursor’, </li></ul></ul><ul><ul><li>‘ select pkey,c1,c2,c3 from t1,t1_st </li></ul></ul><ul><ul><li>where t1.pkey = t1_st.pkey </li></ul></ul><ul><ul><li>and t1_st.last_modified >= ?‘ </li></ul></ul><ul><ul><li>go </li></ul></ul>
    44. 44. Partitioning Rows by Remote User <ul><li>With SQL Remote, on the consolidated database, you could partition rows by remote user by specifying a subscribe by column in the publication definition on the consolidated </li></ul>CREATE TABLE t2 ( pkey integer primary key, data varchar(100), rem_user varchar(128) NOT NULL, last_modified datetime default getdate() ) go sp_create_publication p1 sp_add_remote_table t2 sp_add_article p1, t2, NULL, rem_user sp_add_article_col p1, t2, pkey sp_add_article_col p1, t2, data sp_add_article_col p1, t2, rem_user go
    45. 45. Partitioning Rows by Remote User <ul><li>With MobiLink, because the name of the MobiLink user is passed up in the upload stream, this value is passed into most synchronization scripts, including the download_cursor </li></ul><ul><ul><li>exec ml_add_table_script ‘v1’, ‘t2’, ‘download_cursor’, ‘select pkey,c1,c2,c3 from t2 where last_modified >= ? and rem_user = ?‘ </li></ul></ul><ul><ul><li>go </li></ul></ul><ul><li>With the above download_cursor, only rows meant for a given remote user that have been modified since the download will be synchronized to the remote database, just like SQL Remote </li></ul><ul><li>Note that if you only want to use the ML User paramter, because it’s the second parameter, there must be TWO question marks in your script </li></ul><ul><ul><li>exec ml_add_table_script ‘v1’, ‘t2’, ‘download_cursor’, ‘s elect pkey,c1,c2,c3 fom t2 where ? Is not null and rem_user = ?’ </li></ul></ul><ul><ul><li>go </li></ul></ul>
    46. 46. Downloading Deletes <ul><li>Since MobiLink does not scan the transaction log of the consolidated database, and since downloaded data is based on a SQL statement, another mechanism was needed if you wanted to be able to send deletes to the remote databases in the download stream </li></ul><ul><li>Another download cursor called the download_delete_cursor is used to track which rows should be deleted from the remote database </li></ul><ul><li>A table we refer to as a “Shadow Table” must be maintained to track which rows should be deleted on the remote database </li></ul>
    47. 47. Downloading Deletes <ul><li>Using the same table t2 from the previous slides, we’d create a table called t2_del </li></ul><ul><ul><li>CREATE TABLE t2_del ( </li></ul></ul><ul><ul><li>pkey integer primary key, </li></ul></ul><ul><ul><li>del_time datetime default getdate() </li></ul></ul><ul><ul><li>) </li></ul></ul><ul><ul><li>go </li></ul></ul><ul><li>Note that if you used a shadow table for tracking the last_modified value, you could simply add the del_time column to this table instead of having two separate tables </li></ul>
    48. 48. Downloading Deletes <ul><li>We would also define a delete trigger on t2 that inserted a row into t2_del each time a row was deleted, that tracked the time the row was deleted </li></ul><ul><ul><li>create trigger ad_t2 on t2 for delete as </li></ul></ul><ul><ul><li>begin </li></ul></ul><ul><ul><li>insert into t2 select pkey,getdate() from deleted </li></ul></ul><ul><ul><li>end </li></ul></ul>
    49. 49. Downloading Deletes <ul><li>This now allows us to define our download_delete_cursor for table t2 </li></ul><ul><ul><li>exec ml_add_table_script ‘v1’, ‘t2’, ‘download_delete_cursor’, </li></ul></ul><ul><ul><li>‘ select pkey from t2_del where del_time >= ?‘ </li></ul></ul><ul><ul><li>go </li></ul></ul><ul><li>Note that allowing deletes on shared rows at the remote databases introduces the same possible RI problems that exist in SQL Remote </li></ul>
    50. 50. Territory Re-alignment <ul><li>Territory re-alignment for SQL Remote for ASE is done by maintaining another subscribe by column on the child table that is maintained using triggers on the parent table </li></ul><ul><li>Since all the gear is already in place to maintain the subscribe by column on the child table, the territory re-alignment problem is already solved for MobiLink as well </li></ul><ul><li>It’s simply a matter of adding a where clause on the download_cursor that includes the subscribe by column that is being maintained on the consolidated </li></ul>
    51. 51. Generating Conflict Resolution Scripts <ul><li>To define conflict resolution scripts for SQL Remote for ASE, when adding the table into the list of replicating tables, you would also specify a resolve_procedure, an old_row table and a new_row table </li></ul><ul><li>In MobiLink, you first define a upload_fetch event </li></ul><ul><ul><li>This event fetches the current state of the row being updated, and compares the values to the old row values that were passed up in the upload stream </li></ul></ul><ul><li>If the upload_fetch results do not match the old row values passed up in the upload stream, then the following three table events are fired </li></ul><ul><ul><li>upload_new_row_insert </li></ul></ul><ul><ul><li>upload_old_row_insert </li></ul></ul><ul><ul><li>resolve_conflict </li></ul></ul>
    52. 52. Generating Compatible Conflict Resolution Scripts <ul><li>The three events that fire are incredibly similar to the algorithm used by SQL Remote for ASE </li></ul><ul><ul><li>Your upload_new_row_insert event will insert the new value of the row into a temporary table </li></ul></ul><ul><ul><li>Your upload_old_row_insert event will insert the old value of the row into a temporary table </li></ul></ul><ul><ul><li>Your resolve_conflict event will call the stored procedure that you have already written </li></ul></ul><ul><li>All the logic has already been written if you have defined conflict resolution for SQL Remote for ASE, so writing compatible conflict resolution scripts for MobiLink will be trivial </li></ul>
    53. 53. First Synchronization From Migrated Remote <ul><li>When we discussed migrating the remote databases, we glossed over some important details about what was done on the consolidated database during the first synchronization to ensure that the next download that came from MobiLink did not include all the data that had previously been downloaded through SQL Remote </li></ul><ul><li>When a remote synchronizes for the first time, the last_download value that is passed up is a value of “1900-01-01 00:00:00” </li></ul><ul><li>We can use this fact to recognize that this is a first synchronization and to take some additional steps </li></ul>
    54. 54. First Synchronization From Migrated Remote <ul><li>We’ll define a modify_last_download_timestamp event that will do the following : </li></ul><ul><ul><li>Check and see if the last_download values is Jan 1, 1900 </li></ul></ul><ul><ul><li>If yes, then check and see if the ml_username passed up is also a username that exists in the sr_remoteuser table </li></ul></ul><ul><ul><li>If yes, then get the value of the time_sent column from the sr_remoteuser table for this user </li></ul></ul><ul><ul><ul><li>This represents the time the last SQL Remote message was sent to this user </li></ul></ul></ul><ul><ul><li>Modify the last_download value passed in (Jan 1, 1900) to the time from the sr_remoteuser table </li></ul></ul><ul><ul><li>Remove the SQL Remote user from the sr_remoteuser table so no more SQL Remote messages are sent to this user </li></ul></ul>
    55. 55. First Synch From New MobiLink Client <ul><li>The initial synchronization from a new MobiLink client will have a last_download value of Jan 1, 1900 but will the username will NOT exist in the sr_remoteuser table </li></ul><ul><li>In this case, you do NOT modify the last_download timestamp in the modify_last_download_timestamp event </li></ul>
    56. 56. First Synch From New MobiLink Client <ul><li>Because the initial values of the new last_modified columns were set to ‘1900-01-01 00:01:00’, all rows will be downloaded to the new MobiLink client </li></ul><ul><li>The reason that ‘1900-01-01 00:01:00’ was chosen was because it was greater than ‘1900-01-01 00:00:00’, but guaranteed to be less than the minimum time_sent value in the sr_remoteuser table </li></ul>
    57. 57. Migrating from SSRemote to MobiLink <ul><li>With years of experience iAnywhere Professional Services can deliver tailored services to ensure a successful migration: </li></ul><ul><ul><ul><li>Analysis and review of replication rules </li></ul></ul></ul><ul><ul><ul><li>Design and architect a MobiLink solution equivalent to or enhance your current SSRemote solution </li></ul></ul></ul><ul><ul><ul><li>Develop and test MobiLink scripts </li></ul></ul></ul><ul><ul><ul><li>Provide a customized knowledge transfer </li></ul></ul></ul><ul><ul><ul><li>Deliver MobiLink Synchronization training </li></ul></ul></ul><ul><li>For more information contact your local iAnywhere Solutions sales representative, e-mail [email_address] , visit http://www.ianywhere.com/services or call 1-800-801-2069 </li></ul>
    58. 58. <ul><li>Ask the iAnywhere Experts on the Technology Boardwalk (exhibit hall) </li></ul><ul><ul><li>Drop in during exhibit hall hours and have all your questions answered by our technical experts! </li></ul></ul><ul><ul><li>Appointments outside of exhibit hall hours are also available to speak one-on-one with our Senior Engineers. Ask questions or get your yearly technical review – ask us for details! </li></ul></ul><ul><li>TechWave ToGo Channel </li></ul><ul><ul><li>TechWave To Go, an AvantGo channel providing up-to-date information about TechWave classes, events, maps and more – also, keep up to date with the TechWave Newsletter – now available via your handheld device! </li></ul></ul><ul><ul><li>www.ianywhere.com/techwavetogo </li></ul></ul><ul><li>Mobile and Wireless Email using Pylon Anywhere </li></ul><ul><ul><li>iAnywhere is providing access to your corporate email at TechWave using Pylon Anywhere. You can keep up-to-date with your latest email, calendar, contacts, and tasks from your PDA or any Web-client! Visit the iAnywhere demo station in the Sybase booth or our “Ask the Experts” area in the Technology Boardwalk (Exhibit Hall) for details on how you can evaluate Pylon Anywhere yourself! </li></ul></ul>iAnywhere at TechWave2004
    59. 59. iAnywhere at TechWave2004 <ul><li>Wi-Fi Hotspots – brought to you by Intel </li></ul><ul><ul><li>You can enjoy wireless internet access via Wi-Fi hotspots provided by Intel. Using either a laptop or PDA that is Wi-Fi 802.11b wirelessly-enabled, visitors can access personal email, the internet and “TechWave ToGo” </li></ul></ul><ul><li>Developer Community </li></ul><ul><ul><li>A one-stop source for technical information! </li></ul></ul><ul><ul><li>Access to newsgroups,new betas and code samples </li></ul></ul><ul><ul><li>Monthly technical newsletters </li></ul></ul><ul><ul><li>Technical whitepapers,tips and online product documentation </li></ul></ul><ul><ul><li>Current webcast,class,conference and seminar listings </li></ul></ul><ul><ul><li>Excellent resources for commonly asked questions </li></ul></ul><ul><ul><li>All available express bug fixes and patches </li></ul></ul><ul><ul><li>Network with thousands of industry experts </li></ul></ul><ul><ul><li>http://www.ianywhere.com/developer/ </li></ul></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×