Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.
When you implement synchronization scripts in .NET, you must tell MobiLink where to find the packages, classes, and methods that are contained in your assemblies.
Create your own class or classes. Write a method for each required synchronization event. These methods must be public.
For more information about methods, see Methods.
Each class with non-static methods should have a public constructor. The MobiLink server automatically instantiates each class the first time a method in that class is called for a connection.
Create one or more assemblies. While compiling, reference iAnywhere.MobiLink.Script.dll, which contains a repository of MobiLink server API classes to use in your own .NET methods. iAnywhere.MobiLink.Script.dll is located in the Assembly\v1 subdirectory of your SQL Anywhere installation.
You can compile your class on the command line, or using Visual Studio .NET or another .NET development environment.
See MobiLink server API for .NET reference.
Compile your project.
For example, compile from Visual Studio .NET as follows:
From the VS.NET Project menu, choose Add Existing Item.
From the Open dropdown list, choose Link File.
Note: For Visual Studio .NET, always use the Link File method. Do not use the Add Reference option to reference iAnywhere.MobiLink.Script.dll. The Add Reference option duplicates iAnywhere.MobiLink.Script.dll in the same physical directory as your class assembly, creating problems for the MobiLink server.
Use the Build menu to build your assembly.
You can also compile from the command line, as follows:
Replace dll-path with the path to iAnywhere.MobiLink.Script.dll. for example, in C#:
csc /out:dll-pathout.dll /target:library /reference:dll-pathiAnywhere.MobiLink.Script.dll sync_v1.cs
In the MobiLink system tables in your consolidated database, specify the name of the package, class, and method to call for each synchronization script. No more than one class is permitted per script version.
For example, you can add this information to the MobiLink system tables using the ml_add_dnet_connection_script stored procedure or the ml_add_dnet_table_script stored procedure. The following SQL statement, when run in a SQL Anywhere database, specifies that myNamespace.myClass.myMethod should be run whenever the authenticate_user connection-level event occurs.
CALL ml_add_dnet_connection_script( 'version1', 'authenicate_user', 'myNamespace.myClass.myMethod' )
The fully qualified method name is case sensitive.
As a result of this procedure call, the script_language column of the ml_script system table contains the word dnet. The script column contains the qualified name of a public .NET method.
See ml_add_dnet_connection_script and ml_add_dnet_table_script.
You can also add this information using Sybase Central.
See Adding and deleting scripts.
Instruct the MobiLink server to load assemblies and start the CLR. You tell MobiLink where to locate these assemblies using options on the mlsrv10 command line. There are two options to choose from:
Use -sl dnet ( -MLAutoLoadPath ) This sets the given path to the application base directory and loads all the private assemblies within it. You should use this option in most cases. For example, to load all assemblies located in dll-path, enter:
mlsrv10 -c "dsn=consolidated1" -sl dnet(-MLAutoLoadPath=dll-path)
When you use the -MLAutoLoadPath option you cannot specify a domain when entering the fully qualified method name for the event script.
See Loading assemblies and -sl dnet option.
Use -sl dnet ( -MLDomConfigFile ) This option requires a configuration file that contains domain and assembly settings. You should use this option when you have shared assemblies, when you don't want to load all the assemblies in a directory, or when for some other reason you need to use a configuration file.
For more information about loading shared assemblies, see Loading assemblies. For more information about the mlsrv10 option -sl dnet, see -sl dnet option.
You can use the -MLAutoLoadPath option or the -MLDomConfigFile option, but not both.