Another sync issue surfaced this week in SalesLogix 6.1. This is another one of those fun things to troubleshoot since the data does in fact update on the local database but then is rejected by the remote database in the synchronization process. The problem only exists when using dynamic SQL statements to perform updates or inserts and involves putting blank strings into numeric fields.

A common technique I see in many SalesLogix scripts is where the code grabs the values from textboxes and builds a SQL string. In my case I was grabbing values from other places in the database and using those values in a SQL statement to update other tables. Something like this:

Dim val1
Dim sql

     ' using a value from another table
     val1 = GetAValueFromSomeTable(textbox1.Text)
     sql = "update mytable set myfield = '" & val1 & "'" where something"
     Application.GetNewConnection.Execute sql

     ' or sometimes using a value from a control
     val1 = textbox1.Text
     sql = "update mytable set myfield = '" & val1 & "'" where something"
     Application.GetNewConnection.Execute sql

A pretty common thing you see often in SalesLogix scripts, right? In my case, I was taking some input and then grabbing some associated values from the product tables, along with other values, and then using those in my SQL statements. All seemed fine and appeared to be working as expected.

The problem was that I was updating a float field and the value I was grabbing from the product table turned out to be empty. So my SQL statement had a blank string that I was inserting into a float field. The real problem here was that this statement executed correctly on the local database (as I would expect, the SalesLogix provider works best with strings regardless of the underlying field type - but that's another blog entry). The local database reflected the update correctly. However, when the statement was synchronized out to the remote databases the update/insert statement was rejected because I was inserting a blank string into a float field. So the entire statement was rejected and resulted in the entire change being lost. My guess is that the sync process uses the native database provider, instead of the SalesLogix provider since the change is the result of a sync and not something that needs to sync. The native SQL provider does distinguish between strings and other data types and you'll definately see a problem there.

However, as I mentioned before the result of attempting to insert a blank string into a numeric field is that you'll see the data correctly inserted into the table on the local database, but it will never end up in the remote database as it will be rejected by the sync process once it is attempted to be retrieved into the remote database. I should also point out that this only applies to building SQL statements dymanically. If you use updateable recordsets to perform your inserts & updates then you won't see this problem.