Hi all,
We've just migrated from UL9.0.2 to UL10.0.0 (EBF 2788, Mobilink is
also on this same EBF) and are about to deploy to a new customer, when
doing stress testing we found out that after 10-20 syncs our database
gets corrupted - can't connect and sync won't work anymore (sometimes
just won't sync anymore, but we are able to connect).
Our sync engine is quite large, so we did a small robot to test
whether the problem was on our code or on the UL Synchronize()
method.
First we coded the robot in Appforge Crossfire 6.5.2 C# (the tool we
primarely use) and as the problem manifested itself we went on to code
in native .Net CF C#.
It seems that the problem is on UL Synchronize().

We are deploying for PPC devices and have tested with WM5.0 (Dell Axim
X51v and Eten M600) and Pocket PC 2003 (Harrier) devices.

The two codes (on Crossfire and on .Net CF) are listed below. When the
counter (see common code) reaches more then 10 (depends on database
number of tables), the robot crashes and we are not able to sync
anymore, even after a soft reset - we have to delete the database and
re-create it. We have tested with two database models, one with 57
tables and the other with 62 tables.

----Common code (begin)----
private void btnStart_ClickEvent(object sender, System.EventArgs e)
{
int count = 0;
sync = true;
while (sync)
{
Application.DoEvents();
this.Synchronize();
count++;
lblSync.Text = count.ToString();
lblSync.Refresh();

}
sync = false;
}
----Common code (end)---


----Crossfire 6.5.2 code (begin)----
private void Synchronize()

{

ULDatabaseManager DbMgr = null;
ULConnection conn = null;
DbMgr = new ULDatabaseManagerClass();
conn = DbMgr.OpenConnection(@"CE_FILE=\DB\mSeries.udb");
conn.SyncParms.KeepPartialDownload = false;
conn.SyncParms.ResumePartialDownload = false;
conn.SyncParms.Stream = ULStreamType.ulTCPIP;
conn.SyncParms.StreamParms = txtStreamParams.Text;
conn.SyncParms.Version = txtVersao.Text;
conn.SyncParms.UserName = txtUserName.Text;
conn.SyncParms.SendColumnNames =
chkSendColumnNames.Value == CheckBoxValue.Checked;
conn.SyncParms.SendDownloadAck = chkACK.Value ==
CheckBoxValue.Checked;
conn.SyncParms.DownloadOnly = false;
conn.SyncParms.UploadOnly = false;
conn.SyncParms.PublicationMask = 0;
conn.Synchronize();
conn.Close();
conn = null;
}
----Crossfire 6.5.2 code (end)----

----.Net CF 1.0 code (begin)----
private void Synchronize()

{
ULConnection conn = new ULConnection(@"CE_FILE=\DB
\mseries.udb");
conn.Open();
conn.SyncParms.KeepPartialDownload = false;
conn.SyncParms.ResumePartialDownload = false;
conn.SyncParms.Stream = ULStreamType.TCPIP;
conn.SyncParms.StreamParms = txtStreamParams.Text;
conn.SyncParms.Version = txtVersion.Text;
conn.SyncParms.UserName = txtUserName.Text;
conn.SyncParms.SendColumnNames =
chkSendColumnsNames.Checked;
conn.SyncParms.SendDownloadAck = chkACK.Checked;
conn.SyncParms.DownloadOnly = false;
conn.SyncParms.UploadOnly = false;
conn.SyncParms.PublicationMask = 0;
conn.Synchronize();
conn.Close();
conn = null;
Application.DoEvents();
}
----.Net CF 1.0 code (end)----

Thanks in advance,
Jobson

All the devices you mention show the same problem? Where are you storing
the database (eg. internal/external flash). If its an external card then,
does each device have the same brand of card?

Please open a tech support case for this. We'll need to reproduce you issue
in order to help.

Mike

"Jobson Martins" <jobsonms (AT) gmail (DOT) com> wrote

I have seen similar problem when on Ultralite 8 / Mobillink 8. It was
because you are synching to storage card ? if you change your code to sync
directly into the RAM flash you probably won't see it ... in mycase it was
even much much much faster to sync directly to RAM flash. Then I wrote
wrap-around code to move the udb file back and forth the storage card. My
symptoms where just permanent stalling of the sync ... very difficult to
recreate but it did happen, even different types of SD card's did'nt help.
If we try to load for example 50,000 into one table it would go slower as it
reaches the 50,000 record.

Please someone post the solution that you get from tech support, will help
others having similar issues

On 12 mar, 11:11, "Michael Thode" <mthode_no_s... (AT) sybase (DOT) com> wrote:
After a long weekend, we were able to find a workaround.
It seems that the root problem is related to the following sequence:
-We created a database with several tables, and several publications
inside it;
-We then needed to change one of the tables to make sure that its
sequence of columns was a certain one. Using Sybase Central we had to
delete the table and recreate it. A side effect to that was that a
table "__sctemp001" was created in the UL Schema. We had to do it two
times, and we ended up with "__sctemp001" and "__sctemp002" on our
schema.
-By default we keep the schema in XML store in VSS (Visual Source
Safe), so every time we need to recreate it we use the tool to create
a schema from the XML.
-We tested with an old schema and the problem did not reproduce;
-We realised that the temp tables were the possible culprits, removed
them manually on the XML and recreated the schema;
-Everything worked flawlessly

Hope this helps everyone,
Regards,
Jobson

On 12 mar, 17:05, "Jobson Martins" <jobso... (AT) gmail (DOT) com> wrote:
One last detail: the tables we had to edit were referecend on the
publications.
Regards,
Jobson