FWD » Core Development » Database

This will provide a partial analog (i.e., the subset we need) to PL/Java on SQL Server. The features we need are:

• the ability to load one or more JVMs within the SQL Server database backend process(es);
• a way to register user defined functions implemented in Java within a SQL Server database, possibly dynamically (as opposed to statically loading a jar file into a database as a manual step);
• the ability to back those functions with JNI (or a .NET bridge), so that they are executed in a JVM and the result returned to SQL Server;
• a minimal type mapping between SQL and Java data types, which will allow us to use our existing UDF definitions (i.e., in the com.goldencode.p2j.persist.pl package).

The preferred approach is to use SQL Server C bindings with JNI, but we should investigate the pros and cons of using a .NET/Java bridge.

Preliminary research indicates that using IKVM is feasible and probably represents the simplest solution. Turns out SQL Server does not support C language bindings for UDFs, but it does support .NET.

The scope of this prototype is as a proof of concept:

• writing a simple Java implementation of a UDF;
• compiling it to CIL with IKVMC;
• getting it to loading into SQL Server;
• successfully executing it in a SELECT statement.

Sounds like you're making good headway, Ovidiu.

I attempted to convert the whole p2jpl.jar. Operation finished and wrote an output exe file, but there was tons of warnings (because of the jar dependencies).

What dependencies are those? This jar should stand alone.

The SQL Server can execute 'external' code in two ways:
1. as 'Extended Stored Procedures'. This is the deprecated solution and, even if it is yet available in SQL Server 2012, Microsoft intends to remove this feature in a future version of SQL Server. Developpers are adviced not to use this feature in new development work, and modify applications that currently use this feature as soon as possible.
The extended procedures are also Windows dlls but they need to use a special API in order to be successfully loaded and executed by the Server.
I managed to add (at least it was visible in management console) the test dll converted by ikvm using

   EXEC  sp_addextendedproc 'P2J_Add', 'c:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\Binn\p2j_operators.dll';

However, I was not able to execute anything using this feature because of multiple reasons: * converted dlld most likely did not implement the correct API * the methods from java are mapped to methods from CLR objects. The syntax does not allow it
select Operators.P2J_Add(2, 2) * this concept is built for running trully natibe C/C++ code
I only investigated this as a temporary alternative.

2. the CLR Integration Concept. This enables to write stored procedures, triggers, user-defined
types, user-defined functions, user-defined aggregates, and streaming table-valued functions,
using any .NET Framework language that is compiled to CLI.

I implemented a small test class (c# with sample test funtions simmilar to those needed by p2jpl). I was able to install the assembly into database and perform some basic selects using the UDFs. With this opportunity I discoved that there is a rather strong-typed environment and the names of the methods/functions cannot be overloaded. I believe that psql and h2 also have the same requirements, but the renaming (indexing of the overloaded methods) happens transparently, when installing the cod.
The CLR-SQL type mapping can be found here: [[http://msdn.microsoft.com/en-us/library/bb386947(v=vs.110).aspx]]
We need to check the additional mapping from/to java to CLR.
As mentioned in a previous note the conversion of java code executed without problems. The generated dll has (at least for the simple testcase) two dependencies: IKVM.Runtime.dll and IKVM.OpenJDK.Core.dll. Before adding to database the converted assembly that contain our functions, the dependecies must be added, one at a time. Here is the big problem. The two dlls above mentioned, are mutual dependant. This is rather strange in dll world but possible. The IKVM does a dirty little trick for compiling them, using a two stage compile (this can be found in the chapter 'Additional Information' in the HOWTO document that came with the ikvm sources).
I tried to add the two dlls in a single batch by grouping them using GO sql statement but this was useless.
Other important thing to note is that execution of CLR code must be manually configured for the current database using:

   -- enabling execution oc CLR code on SQL server:
   EXEC sp_configure 'clr enabled';       -- just display the current status, default is 0 (false)
   EXEC sp_configure 'clr enabled' , '1';
   RECONFIGURE;

At this moment I try to build the base dlls as a single compile unit so it will be successfully loaded into SQL server.

Eric Faulhaber wrote:

This is great news! When you are ready, please post an update and detailed instructions about:

• the specific software versions you have used for this POC (Windows, compiler, .NET framework, SQL Server, IKVM, etc.), and (with respect to open source software or free developer editions) how/where to get them;
• compiling/building the assembly from the Java source code;
• installation into a SQL Server database instance.

Software configuration¶

Here is the detailed software configuration (usually they are the latest versions of the free 'distribution' for the downloadable binaries/sources but for some tasks, when special versions are required they are documented):

• Microsoft Windows 7 Home Premium, X86-based (32 bit), 6.1.7601 Service Pack 1 Build 7601
• Microsoft Visual Studio Express 2013 for Windows Desktop (version 12.0.21005.1 REL), running on .NET framework 4.5.50938 (not really needed for our purpose, just for testing of some ideas) [[http://www.visualstudio.com/downloads/download-visual-studio-vs#d-express-windows-desktop]]
• SQL Server Express 2012 (version 2011.110.2100.60) [[http://www.microsoft.com/en-us/download/details.aspx?id=29062]] This version will not be used on production, of course.
• Microsoft SQL Server Management Studio (version 11.0.2100.60), running on .NET Framework 4.0.30319.18408, downloaded with SQL Server Express
• Oracle Java 7 Update 51 [[http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html]]
• .NET Reflector (version 8.3.3.115) (a trial-mode tool used for inspection of generated assemblies, not directly needed for our purpose, just mentioned it here if ever needed again) [[http://www.red-gate.com/dynamic/products/dotnet-development/reflector/download]]
• IKVM (version 7.2.4630.5) [[http://sourceforge.net/projects/ikvm/files/ikvm/7.2.4630.5/]]
• NAnt A .NET Build Tool (only needed to re-compile IKVM, must be version 0.85, the latest, 0.92 won't work!) [[http://sourceforge.net/projects/nant/files/nant/0.85/]]
• OpenJDK 7u6 b24 sources (only needed to re-compile IKVM) [[http://sourceforge.net/projects/ikvm/files/ikvm/7.2.4630.5/]]
• ICSharpCode.SharpZipLib.dll (only needed to re-compile IKVM) [[http://www.icsharpcode.net/opensource/sharpziplib/]]

Building the assembly from the Java source code¶

This is the easy step. The java source code must be first compiled and packed in a jar archive. I used the latest JDK (set in PATH) for these task (no special switches here):

javac Operators.java
jar cfv p2j_operators.jar Operators.class

The second step is converting the jar to dll assembly. If there is a main() method in any compiled classes in the jar, the result of the conversion will be an exe. This is not important, the SQL server will handle both, equally. At least for the very simple test-case the conversion command is straightforward:

ikvmc p2j_operators.jar

A new file p2j_operators.exe will be created. If the main() method has some test-cases these can be run at this moment to verify the conversion (eventually, some of the IKVM dlls must be made available, or else the application will crash).

Installation into a SQL Server database instance.¶

Before installation of the new code, there are a few steps that must be performed:

• Enabling execution of CLR code on SQL server:
  

  EXEC sp_configure 'clr enabled';
  EXEC sp_configure 'clr enabled' , '1';
  RECONFIGURE;
  

  
  Of course, the first line will print the status of the 'clr enabled' flag. If already set to 1, no need to run the next two lines.
• Set
  

  ALTER DATABASE p2j_test SET TRUSTWORTHY ON
  

  
  This is needed for installing IKVM assemblies. However, I need to double-check if this is really needed on a clean database. I will update this note when I know for sure.
• The .NET framework or SQL Server seem to gave a glitch, the following files Accessibility.dll, System.Drawing.dll, System.Runtime.Serialization.Formatters.Soap.dll and System.Windows.Forms.dll from \Windows\Microsoft.NET\Framework\v4.0.30319 should be copied to ikvm\bin directory.
• Time to install the IKVM assemblies (will install all dependencies recursivelly)
  

  CREATE ASSEMBLY ikvm_runtime
  FROM 'c:\Program Files\ikvm-7.2.4630.5\bin\IKVM.Runtime.dll'
  WITH PERMISSION_SET = UNSAFE
  
  CREATE ASSEMBLY ikvm_openjdk_jdbc
  FROM 'c:\Program Files\ikvm-7.2.4630.5\bin\IKVM.OpenJDK.Jdbc.dll'
  WITH PERMISSION_SET = UNSAFE
  

  
  The second assembly tree is needed if classes form java.sql.* are involved (like Date and Timestamp).
• Now we can finally insert into database out assembly:
  

  CREATE ASSEMBLY [p2j_operators]
  AUTHORIZATION [dbo]
  FROM 'c:\Work\1stSqlProject\P2JMsSql1\java\p2j_operators.dll'
  WITH PERMISSION_SET = SAFE
  

• In order to be used by SQL queries, we need to define SQL functions based on the 'external' functions imported previously:
  

  CREATE FUNCTION [dbo].[P2J_Add32bitScalars]
  (@param1 INT, @param2 INT)
  RETURNS INT
  AS EXTERNAL NAME p2j_operators.Operators.P2J_Add32bitScalars
  

  
  The SQL functions cannot be overloaded and the exact type mapping must be used. The sql name does not need to be the same with the one from java/CLR.
• At this moment, hoping there were no errors, we can use our functions:
  

  select [dbo].[P2J_Add32bitScalars](-10, 20) as 'int';
  

I have attached the updates Operators source and a SQL script with commands/queries used. Note that multiple SQL function definitions cannot appear in a single BATCH, they need to be executes one at a time or separated by GO statements.

My idea is to implement the requested interface for SQL server and defer the processing to a component. The same pattern is used for both java/ikvm and p2j classes.

• using the java/ikvm backing classes allows to use the existing Functions/Operators static functions in SQL
• using p2j classes directly have no obvious advantage, need to study this further on.

I have created a C# class that will be mapped to SQL BIT that wraps the P2J com.goldencode.p2j.util.logical (attached). The only communication with SQL clients is via string format through two methods: ToString() and Parse(SqlString s). NULL values are handled in dedicated code. The persistence to SQL database can be left to SERVER "native" (probably the entire objects are serialized) and also can be manually serialized using Write(System.IO.BinaryWriter w) and Read(System.IO.BinaryReader r) - similar to our serialization - in a more optimized manner.
Unfortunately, as far as I understand, there is no possibility to do implicit casting to and from native datatypes. The only solution is via the string format as shortly described above.

Shortly, to install the assembly, the following steps should be followed:

• compile p2jpl.jar to an library (dll or exe) and install it as an assembly in database in SQL (as in one of my previous posts). Because of its content, it can only be created with PERMISSION_SET = UNSAFE.
• compile the P2JLogical.cs (and all other similar C# classes) into a P2JWrapper.dll. Install it also as an assembly.
• now we can create our UDTs:
  

  CREATE TYPE P2JLogical EXTERNAL NAME [p2j_wrapper].[P2JLogical]
  

  
  We will have to repeat this for each P2J type.
• Now create the table directly with the new UDTs:
  

  CREATE TABLE [p2j_wrappers] (
      [id] [bigint] IDENTITY(21764, 17) NOT NULL,
      [p2j_logical] [P2JLogical] NULL,
      [sql_logical] [BIT] NULL
  ) ON [PRIMARY]
  

• to populate the table we need to pass the values as strings, except for NULL s that will be used as such.
  

  INSERT INTO [p2j_wrappers] VALUES ('true', 1)
  INSERT INTO [p2j_wrappers] VALUES ('1', 1)
  -- INSERT INTO [p2j_wrappers] VALUES (1, 1) <-- fails, Operand type clash: int is incompatible with P2JLogical
  INSERT INTO [p2j_wrappers] VALUES ('false', 0)
  INSERT INTO [p2j_wrappers] VALUES ('0', 0)
  -- INSERT INTO [p2j_wrappers] VALUES (0, 0) <-- fails, Operand type clash: int is incompatible with P2JLogical
  INSERT INTO [p2j_wrappers] VALUES (NULL, null)
  

• finally we can query the data:
  

  SELECT * FROM [p2j_wrappers]
  SELECT [p2j_logical], [sql_logical] FROM [p2j_wrappers]
  

Note that SQL Server allows that CLR methods to be applied directly to UDT:

SELECT [p2j_logical].P2J_And('falsE'),
       [p2j_logical].P2J_And(' true') 
   FROM [p2j_wrappers]

I wonder if this could come in handy to use as an alternative to Functions / Operations: each method of these classes to be replaced by such a method of the first argument and drop the UDF at all. So instead of writing SELECT p2j_and(a, b) FROM table1 we will have SELECT a.and(b) FROM table1. I think this will avoid the method overloading mentioned in a previous post. But this is just an idea, must test is HQL can support it for a dialect.

An issue I found are SQL statements like:

SELECT * FROM [p2j_wrappers] WHERE [p2j_logical]

The evident solution is to rewrite it as:

SELECT * FROM [p2j_wrappers] WHERE [p2j_logical] = '1'

But this looks bad. I intended to find a solution and added a method that returns the values as a bool (this is the mapped type of SQL BIT type). This way the query becomes:

SELECT * FROM [p2j_wrappers] WHERE [p2j_logical].value()

This won't work. Later I discovered that the 'native' case also does not:

SELECT * FROM [p2j_wrappers] WHERE [sql_logical]

Instead the value() can be used to extract the native value from UDT:

SELECT [p2j_logical].value(), [p2j_logical].P2J_And('true').value() FROM [p2j_wrappers]

During the last days I tried to find a solution for compiling / converting previously attached files in linux using ikvm and mono cross-compiling.

Linux has in the repositories an old version of the IKVM: 0.46.0.1. The problem is that this will convert but only java code that was generated by JDK6 and previous.
On the ikvm.net there are some new version of IKVM 7.x. But they only compile for windows / .net. To use it in linux a little trick must be used, the conversion must be run from Mono.

The windows build of IKVM need to be downloaded and installed in file-system. I used /usr/bin/ikvm/bin for binaries and /usr/lib/ikvm/ for libraries.

Now we can convert the p2jpl:

mono /usr/bin/ikvm/bin/ikvmc.exe -target:library lib/p2jpl.jar -out:bin/p2jpl.dll -version:0.0.1.0

then build the SqlUserDefinedType adapter assembly and the small test application:

mcs -r:/usr/lib/ikvm/IKVM.OpenJDK.Core.dll -r:bin/p2jpl.dll -r:System.Data.dll -target:library -out:bin/P2JLogical.dll src/P2JLogical.cs
mcs -r:/usr/lib/ikvm/IKVM.OpenJDK.Core.dll -r:bin/P2JLogical.dll -r:System.Data.dll -target:exe -out:bin/TestApp1.exe src/TestApp1.cs

At this moment, running the test application on Linux with Mono, fails with following error:

Unhandled Exception: System.TypeLoadException: A type load exception has occurred.
  at com.goldencode.p2j.util.logical..ctor (System.String value) [0x00000] in <filename unknown>:0 
  at P2JLogical.Parse (SqlString s) [0x00000] in <filename unknown>:0 
  at TestApp1.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: A type load exception has occurred.
  at com.goldencode.p2j.util.logical..ctor (System.String value) [0x00000] in <filename unknown>:0 
  at P2JLogical.Parse (SqlString s) [0x00000] in <filename unknown>:0 
  at TestApp1.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 

Apparently, the logical(String) c'tor is not processed correctly. Googling this shows that a library issue may be the cause even Mono itself.

On Windows the application crashes with the following error:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Data, Version=4.0.0.0, Cul
ture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
   at TestApp1.Program.Main(String[] args)

At first look the .NET assemblies are not found where they are supposed to be.

On SQL server, the assemblies will load in database, even the UDT and tables can be created with them.
However, when running a query that uses the new UDT the following error is printed:

Msg 6522, Level 16, State 1, Line 1
A .NET Framework error occurred during execution of user-defined routine or aggregate "P2JLogical": 
System.Security.SecurityException: Request failed.
System.Security.SecurityException: 
   at P2JLogical.Parse(SqlString s)

I am continuing with investigations.

At some time, I tried to compile with the old IKVM (using a trimmed version of p2jpl that compiled with javac -target 6) and the execution of the test application was successful.
I also tried to access directly the P2JPL in TestApp2. This was also successful.
I am missing something here...

I discovered the errors from my previous note. The generated assemblies are compiled against different .Net frameworks so the Framework refused to load and execute them. It's a strange thing but, using the same parameters the on Windows, the target is version is v2.0.50727, while on Linux with Mono, the default is v4.0.30319.

The .Net target version can be check on windows using CorFlags utility that can be found in a place similar to

c:\Program Files\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\CorFlags.exe

On Mono/Linux I found

monop2 --runtime-version bin/p2jpl.dll

but it will print the global runtime (runtime version: 4.0.30319.1), not the version extracted from actual file.

Because of the raised security checks in .Net 4.0, SQL Server refuses to execute our code converted to CLR probably because of some native code exiting in FileChecker, LaunchManager, MemoryManager, Registry. The generated code targeting .NET 2.0 (as generated by default by IKVM on windows) does not have such restrictions so the assemblies are loaded successfully.
To obtain the converted code targeting the .Net 2.0 on Mono/Linux the default assembly references need to be ignored and manually specify the desired ones. The compile script must be adjusted as follows:

mono --runtime=v2.0.50727 /usr/bin/ikvm/bin/ikvmc.exe -target:library -nostdlib -r:/usr/lib/mono/2.0/mscorlib.dll -r:/usr/lib/mono/2.0/System.dll -out:bin/p2jpl.dll -version:0.0.1.1 lib/p2jpl.jar

dmcs -r:/usr/lib/mono/2.0/cscompmgd.dll -r:System.Windows.Forms -r:/usr/lib/ikvm/IKVM.OpenJDK.Core.dll -r:bin/p2jpl.dll -pkg:dotnet -target:library -out:bin/P2JWrappers.dll src/P2JLogical.cs src/P2JInt64.cs src/AssemblyInfo.cs

dmcs -r:/usr/lib/mono/2.0/cscompmgd.dll -r:/usr/lib/ikvm/IKVM.OpenJDK.Core.dll -r:bin/P2JWrappers.dll -pkg:dotnet -target:exe -out:bin/TestApp1.exe src/TestApp1.cs

For that, the following prerequisites are needed:

• make sure the mono-complete package is installed
• the IKVM (vs. 0.46.0.1) from Linux repository must be completely uninstalled
• the latest IKVM (vs. 7.2.4630.5) should be configured (I installed to the same locations as removed version: the executable binaries to /usr/bin/ikvm and the assemblies to /usr/lib/ikvm)
• the IKVM assemblies must be added to the Global Assembly Cache. The best way to do this is using a shell script (with root rights) like this:
  

      for line in $(find /usr/lib/ikvm/ -iname '*.dll'); do 
          gacutil -i "$line" 
      done
  

  
  This will make the assemblies accessible for all later commands.

One more issue arises: how to handle no overloaded methods constraint ?
More than one method, property or field was found with name 'P2J_Add' in class 'P2JInt64' in assembly 'P2JWrappers'. Overloaded methods, properties or fields are not supported.
Operators and Functions have an abundance of such methods. Should we use type decorations resolved in HQL, too?

Hurray!
I have fixed all issues mentioned in my previous notes and successfully run some basic 4GL statements using that are converted in queries using p2jpl functions.

I am attaching an update with some issues that need to be fixed (however, not all of them are related to MS SQL server).

I will write tomorrow a summary of the solution and step by step configuration, because the thread became dirty with my notes regarding some dead-ends I reached during my investigations.

The attached update pack contains some missing files from previous archive. Please review.
The C# source code were temporarily added to src/com/goldencode/p2j/persist/pl, however, I believe they should be moved to native/ or something more appropriate.

• Prerequisites
  The following tools should be installed and configured
  1. IKVM see note 17 above.
  2. full Mono and C# cross compiler (same note 17)
  3. sqsh and freetds installed and configured with the Windows machine
  4. a working directory from where all the following commands will be executed with following empty dirs: src / lib / bin

• Build/convert the p2j project and copy the p2jpl.jar to lib folder:
  In the the p2j.cfg.xml the database should declare sqlserver2012 as supported dialect:
  

  <parameter name="ddl-dialects" value="h2,postgresql,sqlserver2012" />
  

  
  If all goes well, the ddl/schema_table_<dbname>_sqlserver2012.sql will begin with (a lot of) statements that create external UDFs from our assembly.

• Convert the p2jpl.jar to an assembly:
  

  mono --runtime=v2.0.50727 /usr/bin/ikvm/bin/ikvmc.exe -target:library lib/p2jpl.jar -nostdlib -r:/usr/lib/mono/2.0/mscorlib.dll -r:/usr/lib/mono/2.0/System.dll -out:bin/p2jpl.dll -version:0.0.1.1 2> p2jpl_conv.log
  

  
  The p2jpl.dll will be generated in /bin folder. A rather big log file will be created in the current folder (p2jpl_conv.log) with lots of warnings and hopefully, no errors.

• Gather C# source files:
  Copy *.cs files (AssemblyInfo.cs, Common.cs, Functions.cs, Operators.cs) from src/com/goldencode/p2j/persist/pl/ of the p2j project to src/ folder.

• Cross-compile the C# sources:
  

  dmcs -r:/usr/lib/mono/2.0/cscompmgd.dll -r:System.Windows.Forms -r:/usr/lib/ikvm/IKVM.OpenJDK.Core.dll -r:/usr/lib/ikvm/IKVM.OpenJDK.Jdbc.dll -r:bin/p2jpl.dll -pkg:dotnet -target:library -out:bin/p2j2clr.dll src/*.cs &> p2j2clr_compile.log
  

  
  You can inspect the output using:
  

        monop2 -r:bin/p2j2clr.dll
        monop2 -r:bin/p2j2clr.dll Functions | less
        monop2 -r:bin/p2j2clr.dll Operators | less
  

• Copy the output files
  Copy generated files (dlls from bin/ folder) to Windows machine where the SQL Server is running (ex: in C:\Work\x-compiled\). Make sure the following files can also be found in the same location:
  IKVM Runtime support (about 22 files),
  Additional files from .NET: System.Drawing.dll, System.Windows.Forms.dll, Accessibility.dll, System.Runtime.Serialization.Formatters.Soap.dll.

• Install our support binaries:
  After the database (p2j_test) has been created connect with sqsh to SQL Server and execute:
  

  USE p2j_test
  go
  ALTER DATABASE p2j_test SET TRUSTWORTHY ON
  go
  CREATE ASSEMBLY [IKVM.Runtime] FROM 'C:\Work\x-compiled\IKVM.Runtime.dll' WITH PERMISSION_SET = UNSAFE
  go
  CREATE ASSEMBLY [IKVM.OpenJDK.Jdbc] FROM 'C:\Work\x-compiled\IKVM.OpenJDK.Jdbc.dll' WITH PERMISSION_SET = UNSAFE
  go
  CREATE ASSEMBLY p2jpl FROM 'C:\Work\x-compiled\p2jpl.dll' WITH PERMISSION_SET = UNSAFE
  go
  CREATE ASSEMBLY p2j2clr FROM 'C:\Work\x-compiled\p2j2clr.dll' WITH PERMISSION_SET = UNSAFE
  go
  

  
  Note:
  the paths given in these sql statements are relative to Windows machine even if they are launched from linux console.
  Now you can install the rest of the database using generated ddl/schema_table_p2j_test_sqlserver2012.sql.

• Install SQL Server driver:
  Download Microsoft JDBC Driver 4.0 for SQL Server from [[http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11774]]. Add sqljdbc4.jar with the rest of the libraries.

• Configure p2j runtime:
  Use the following settings in directory.xml in the database/p2j_test/hibernate section:
  

  <node class="container" name="hibernate">
      <node class="string" name="dialect">
          <node-attribute name="value" value="com.goldencode.p2j.persist.dialect.P2JSQLServer2012Dialect"/>
      </node>
      <node class="container" name="connection">
          <node class="string" name="driver_class">
              <node-attribute name="value" value="com.microsoft.sqlserver.jdbc.SQLServerDriver"/>
          </node>
          <node class="string" name="url">
              <node-attribute name="value" value="jdbc:sqlserver://192.168.0.11:1433;databaseName=p2j_test"/>
          </node>
          <node class="string" name="username">
              <node-attribute name="value" value="p2j"/>
          </node>
          <node class="string" name="password">
              <node-attribute name="value" value="p2j"/>
          </node>
     ....
  

  
  Use the appropriate values for server name/ip, server port, user and password.

• Launch the P2J application

Changes in update zip:

• removed Operators.java (it was identical to bzr version)
• added full implementation of Operators.cs