Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Initial sync with Ultralite

23 posts in Ultralite Last posting was on 2011-10-21 07:10:54.0Z
Shao Chan Posted on 2011-09-30 19:07:18.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
Subject: Initial sync with Ultralite
Lines: 21
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e861366@forums-1-dub>
Date: 30 Sep 2011 12:07:18 -0700
X-Trace: forums-1-dub 1317409638 10.22.241.152 (30 Sep 2011 12:07:18 -0700)
X-Original-Trace: 30 Sep 2011 12:07:18 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12603
Article PK: 1048391

Hi all,

If writing an application using Android Ultralite and keeping the UDB as
part of the project build, ideally I'd want to be able to do an initial sync
to get the majority of static lookup table data (e.g. I have one lookup
table with 60K rows) but not commit a user to the database.

This database would then be shipped with the application and then when the
user logs on they don't need to sync all the referential data.

Obviously, as this database will be part of the application and given to
every user so the initial sync has to be with a special user of some kind.

Is this possible to achieve this or is this kind of functionality in the
pipeline?

Thanks,

Shao


Graham Hurst [Sybase iAnywhere] Posted on 2011-10-04 21:49:56.0Z
From: "Graham Hurst [Sybase iAnywhere]" <spam_guard_hurst@ianywhere.com>
Organization: Sybase iAnywhere
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
Newsgroups: sybase.public.sqlanywhere.ultralite
Subject: Re: Initial sync with Ultralite
References: <4e861366@forums-1-dub>
In-Reply-To: <4e861366@forums-1-dub>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8b7f84$1@forums-1-dub>
Date: 4 Oct 2011 14:49:56 -0700
X-Trace: forums-1-dub 1317764996 10.22.241.152 (4 Oct 2011 14:49:56 -0700)
X-Original-Trace: 4 Oct 2011 14:49:56 -0700, vip152.sybase.com
Lines: 39
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12604
Article PK: 1048382

It would be simplest to use something other than synchronization to
pre-populate the template database.

The problem is that every remote database has to have a unique remote
ID, and synchronization assigns a remote ID (see
http://dcx.sybase.com/index.html#1201/en/mlclient/mc-users-s-6422554.html*d5e595).
If you copy a synchronized database, you have to clear the remote ID and
probably clear anything associated with it from the consolidated database.

It's much safer to copy a template database that has never been
synchronized than to have to clean one that has been synchronized.

Cheers,

Graham

On 2011-09-30 3:07 PM, Shao Chan wrote:
> Hi all,
>
> If writing an application using Android Ultralite and keeping the UDB as
> part of the project build, ideally I'd want to be able to do an initial sync
> to get the majority of static lookup table data (e.g. I have one lookup
> table with 60K rows) but not commit a user to the database.
>
> This database would then be shipped with the application and then when the
> user logs on they don't need to sync all the referential data.
>
> Obviously, as this database will be part of the application and given to
> every user so the initial sync has to be with a special user of some kind.
>
> Is this possible to achieve this or is this kind of functionality in the
> pipeline?
>
> Thanks,
>
> Shao
>
>


Shao Chan Posted on 2011-10-05 07:38:56.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 76
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8c0990@forums-1-dub>
Date: 5 Oct 2011 00:38:56 -0700
X-Trace: forums-1-dub 1317800336 10.22.241.152 (5 Oct 2011 00:38:56 -0700)
X-Original-Trace: 5 Oct 2011 00:38:56 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12605
Article PK: 1048378

Hi Graham,

Thanks for that.

So, when you say to populate the template database, I assume you're meaning
that I should export from the SQL Anywhere database and import into the
Ultralite on the server using DML scripts? Is there a better/easier way of
achieving this?

I was thinking that a lot of business applications will have a situation
where a lot of lookup data is required - in many situations where workmen
lookup data on a table rather than browing a 5000 page manual for a code,
etc. It would be great to have an easy way of getting this data
pre-installed onto the database.

In other situations, customers will setup their own cost data which may
change annually. Ideally I'd rather initially send out a blank database
with the application, but for some customers, once the SQL Anywhere database
is all correctly setup with all the data to do an initial sync, find an easy
way to remove any remote id etc, and compile it into the application so that
it goes out with a database with the correct lookup data.

Any changes in the Ultralite products (even a ulsync command to say
ulsync -delete remoteid or something) to achieve the desired effect?

Thanks,

Shao

"Graham Hurst [Sybase iAnywhere]" <spam_guard_hurst@ianywhere.com> wrote in
message news:4e8b7f84$1@forums-1-dub...
> It would be simplest to use something other than synchronization to
> pre-populate the template database.
>
> The problem is that every remote database has to have a unique remote ID,
> and synchronization assigns a remote ID (see
> http://dcx.sybase.com/index.html#1201/en/mlclient/mc-users-s-6422554.html*d5e595).
> If you copy a synchronized database, you have to clear the remote ID and
> probably clear anything associated with it from the consolidated database.
>
> It's much safer to copy a template database that has never been
> synchronized than to have to clean one that has been synchronized.
>
> Cheers,
>
> Graham
>
> On 2011-09-30 3:07 PM, Shao Chan wrote:
>> Hi all,
>>
>> If writing an application using Android Ultralite and keeping the UDB as
>> part of the project build, ideally I'd want to be able to do an initial
>> sync
>> to get the majority of static lookup table data (e.g. I have one lookup
>> table with 60K rows) but not commit a user to the database.
>>
>> This database would then be shipped with the application and then when
>> the
>> user logs on they don't need to sync all the referential data.
>>
>> Obviously, as this database will be part of the application and given to
>> every user so the initial sync has to be with a special user of some
>> kind.
>>
>> Is this possible to achieve this or is this kind of functionality in the
>> pipeline?
>>
>> Thanks,
>>
>> Shao
>>
>>
>


Tim McClements [Sybase] Posted on 2011-10-05 18:56:13.0Z
From: "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 103
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8ca84d$1@forums-1-dub>
Date: 5 Oct 2011 11:56:13 -0700
X-Trace: forums-1-dub 1317840973 10.22.241.152 (5 Oct 2011 11:56:13 -0700)
X-Original-Trace: 5 Oct 2011 11:56:13 -0700, vip152.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12606
Article PK: 1048379

You could pre-populate using ulsync, ulinit (from a reference database), or
ulload (from an XML file). Note that ulinit and ulload have special
functionality such that the rows they insert will _not_ be uploaded on a
subsequent sync. (If you run your own insert statements you will have this
problem.)

I agree that doing an initial sync is a natural way to do this, and that's
fine. All you have to do is execute "set option ml_remote_id=" after
syncrhonizing to clear the remote ID. Here's a command which does that:

dbisql -ul -c dbf=t.udb "set option ml_remote_id="

If desired you could also set the remote ID to something specific before
doing the initial sync, to avoid adding extra remote ID entries to the ML
system tables.

dbisql -ul -c dbf=t.udb "set option ml_remote_id=initial_sync"
ulsync ...

- Tim

"Shao Chan" <nospam@nospam.com> wrote in message
news:4e8c0990@forums-1-dub...
> Hi Graham,
>
> Thanks for that.
>
> So, when you say to populate the template database, I assume you're
> meaning that I should export from the SQL Anywhere database and import
> into the Ultralite on the server using DML scripts? Is there a
> better/easier way of achieving this?
>
> I was thinking that a lot of business applications will have a situation
> where a lot of lookup data is required - in many situations where workmen
> lookup data on a table rather than browing a 5000 page manual for a code,
> etc. It would be great to have an easy way of getting this data
> pre-installed onto the database.
>
> In other situations, customers will setup their own cost data which may
> change annually. Ideally I'd rather initially send out a blank database
> with the application, but for some customers, once the SQL Anywhere
> database is all correctly setup with all the data to do an initial sync,
> find an easy way to remove any remote id etc, and compile it into the
> application so that it goes out with a database with the correct lookup
> data.
>
> Any changes in the Ultralite products (even a ulsync command to say
> ulsync -delete remoteid or something) to achieve the desired effect?
>
> Thanks,
>
> Shao
>
>
> "Graham Hurst [Sybase iAnywhere]" <spam_guard_hurst@ianywhere.com> wrote
> in message news:4e8b7f84$1@forums-1-dub...
>> It would be simplest to use something other than synchronization to
>> pre-populate the template database.
>>
>> The problem is that every remote database has to have a unique remote ID,
>> and synchronization assigns a remote ID (see
>> http://dcx.sybase.com/index.html#1201/en/mlclient/mc-users-s-6422554.html*d5e595).
>> If you copy a synchronized database, you have to clear the remote ID and
>> probably clear anything associated with it from the consolidated
>> database.
>>
>> It's much safer to copy a template database that has never been
>> synchronized than to have to clean one that has been synchronized.
>>
>> Cheers,
>>
>> Graham
>>
>> On 2011-09-30 3:07 PM, Shao Chan wrote:
>>> Hi all,
>>>
>>> If writing an application using Android Ultralite and keeping the UDB as
>>> part of the project build, ideally I'd want to be able to do an initial
>>> sync
>>> to get the majority of static lookup table data (e.g. I have one lookup
>>> table with 60K rows) but not commit a user to the database.
>>>
>>> This database would then be shipped with the application and then when
>>> the
>>> user logs on they don't need to sync all the referential data.
>>>
>>> Obviously, as this database will be part of the application and given to
>>> every user so the initial sync has to be with a special user of some
>>> kind.
>>>
>>> Is this possible to achieve this or is this kind of functionality in the
>>> pipeline?
>>>
>>> Thanks,
>>>
>>> Shao
>>>
>>>
>>
>
>


Shao Chan Posted on 2011-10-06 11:04:47.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 140
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8d8b4f$1@forums-1-dub>
Date: 6 Oct 2011 04:04:47 -0700
X-Trace: forums-1-dub 1317899087 10.22.241.152 (6 Oct 2011 04:04:47 -0700)
X-Original-Trace: 6 Oct 2011 04:04:47 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12608
Article PK: 1048383

Hi Tim,

Thanks for that.

Just one question. Synchronisation usually is timestamp based.

If we do an initial sync and then remove the remoteid, we'd still want to
ensure that when the user logs in with the real user that the data doesn't
come down again.

I.e.
Time t1 - SQL Anywhere database loaded with all data.
Time t2 - Ultralite syncs with R1
Time t3 - Ultralite R1 user is removed but synched until time t2 is
remembered.
Time t4 - Ultralite syncs with R2 remembering to sync since time t2

If I recall correctly, possibly this time of last sync is held on the SQL
Anywhere database somewhere and only is reset if the user's udb is deleted.
I believe that's how it works in 9.0.2. in our database.

Will remembering not to sync before time t2 have to be hard coded into our
application somewhere if we use this approach or is that already/easily
taken care of?

Cheers,

Shao

"Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
news:4e8ca84d$1@forums-1-dub...
> You could pre-populate using ulsync, ulinit (from a reference database),
> or ulload (from an XML file). Note that ulinit and ulload have special
> functionality such that the rows they insert will _not_ be uploaded on a
> subsequent sync. (If you run your own insert statements you will have this
> problem.)
>
> I agree that doing an initial sync is a natural way to do this, and that's
> fine. All you have to do is execute "set option ml_remote_id=" after
> syncrhonizing to clear the remote ID. Here's a command which does that:
>
> dbisql -ul -c dbf=t.udb "set option ml_remote_id="
>
> If desired you could also set the remote ID to something specific before
> doing the initial sync, to avoid adding extra remote ID entries to the ML
> system tables.
>
> dbisql -ul -c dbf=t.udb "set option ml_remote_id=initial_sync"
> ulsync ...
>
> - Tim
>
> "Shao Chan" <nospam@nospam.com> wrote in message
> news:4e8c0990@forums-1-dub...
>> Hi Graham,
>>
>> Thanks for that.
>>
>> So, when you say to populate the template database, I assume you're
>> meaning that I should export from the SQL Anywhere database and import
>> into the Ultralite on the server using DML scripts? Is there a
>> better/easier way of achieving this?
>>
>> I was thinking that a lot of business applications will have a situation
>> where a lot of lookup data is required - in many situations where workmen
>> lookup data on a table rather than browing a 5000 page manual for a code,
>> etc. It would be great to have an easy way of getting this data
>> pre-installed onto the database.
>>
>> In other situations, customers will setup their own cost data which may
>> change annually. Ideally I'd rather initially send out a blank database
>> with the application, but for some customers, once the SQL Anywhere
>> database is all correctly setup with all the data to do an initial sync,
>> find an easy way to remove any remote id etc, and compile it into the
>> application so that it goes out with a database with the correct lookup
>> data.
>>
>> Any changes in the Ultralite products (even a ulsync command to say
>> ulsync -delete remoteid or something) to achieve the desired effect?
>>
>> Thanks,
>>
>> Shao
>>
>>
>> "Graham Hurst [Sybase iAnywhere]" <spam_guard_hurst@ianywhere.com> wrote
>> in message news:4e8b7f84$1@forums-1-dub...
>>> It would be simplest to use something other than synchronization to
>>> pre-populate the template database.
>>>
>>> The problem is that every remote database has to have a unique remote
>>> ID, and synchronization assigns a remote ID (see
>>> http://dcx.sybase.com/index.html#1201/en/mlclient/mc-users-s-6422554.html*d5e595).
>>> If you copy a synchronized database, you have to clear the remote ID and
>>> probably clear anything associated with it from the consolidated
>>> database.
>>>
>>> It's much safer to copy a template database that has never been
>>> synchronized than to have to clean one that has been synchronized.
>>>
>>> Cheers,
>>>
>>> Graham
>>>
>>> On 2011-09-30 3:07 PM, Shao Chan wrote:
>>>> Hi all,
>>>>
>>>> If writing an application using Android Ultralite and keeping the UDB
>>>> as
>>>> part of the project build, ideally I'd want to be able to do an initial
>>>> sync
>>>> to get the majority of static lookup table data (e.g. I have one lookup
>>>> table with 60K rows) but not commit a user to the database.
>>>>
>>>> This database would then be shipped with the application and then when
>>>> the
>>>> user logs on they don't need to sync all the referential data.
>>>>
>>>> Obviously, as this database will be part of the application and given
>>>> to
>>>> every user so the initial sync has to be with a special user of some
>>>> kind.
>>>>
>>>> Is this possible to achieve this or is this kind of functionality in
>>>> the
>>>> pipeline?
>>>>
>>>> Thanks,
>>>>
>>>> Shao
>>>>
>>>>
>>>
>>
>>
>
>


Reg Domaratzki [Sybase] Posted on 2011-10-06 13:35:26.0Z
From: "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com>
Reply-To: firstname.lastname@sybase.com
Organization: Sybase, an SAP Company
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
Newsgroups: sybase.public.sqlanywhere.ultralite
Subject: Re: Initial sync with Ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub>
In-Reply-To: <4e8d8b4f$1@forums-1-dub>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8dae9e@forums-1-dub>
Date: 6 Oct 2011 06:35:26 -0700
X-Trace: forums-1-dub 1317908126 10.22.241.152 (6 Oct 2011 06:35:26 -0700)
X-Original-Trace: 6 Oct 2011 06:35:26 -0700, vip152.sybase.com
Lines: 87
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12610
Article PK: 1048381


On 10/6/2011 7:04 AM, Shao Chan wrote:
> Hi Tim,
>
> Thanks for that.
>
> Just one question. Synchronisation usually is timestamp based.
>
> If we do an initial sync and then remove the remoteid, we'd still want to
> ensure that when the user logs in with the real user that the data doesn't
> come down again.
>
> I.e.
> Time t1 - SQL Anywhere database loaded with all data.
> Time t2 - Ultralite syncs with R1
> Time t3 - Ultralite R1 user is removed but synched until time t2 is
> remembered.
> Time t4 - Ultralite syncs with R2 remembering to sync since time t2
>
> If I recall correctly, possibly this time of last sync is held on the SQL
> Anywhere database somewhere and only is reset if the user's udb is deleted.
> I believe that's how it works in 9.0.2. in our database.
>
> Will remembering not to sync before time t2 have to be hard coded into our
> application somewhere if we use this approach or is that already/easily
> taken care of?
>
> Cheers,
>
> Shao
>
>

Shao, if the data that you are pre-populating into the ULDB is from
tables that are also synchronize using a timestamp based approach,
you'll have this problem regardless of how you initially populate the
ULDB.

Here's one option:

When you initially populate the database with data at time "t2" (it's
important to note that time "t2" is the time that you pulled the data
from the consolidate, and it's the time at the consolidated database), I
would suggest storing time "t2" in your remote database, possibly in a
table that doesn't synch. Now, whenever you synchronize, you send up an
authentication parameter that will tell the MobiLink Server at what time
the subset of initial data was generated for this remote. You can now
change your synchronization scripts on tables that included initial data
to read :

select pk,c1,c2
from t1
where last_mod >= max( {ml s.last_table_download}, {ml a.1} )

So, for the initial synch, when {ml s.last_table_download} is
'1900-01-01 00:00:00.000', the authentication parameter will be used,
but in subsequent synchs, {ml s.last_table_download} will be greater
than {ml a.1}.

This does mean that you're sending an authentication parameter that's
around 20 bytes in size for every synchronization, but it will allow you
to pre-populate your remote database with some of the data, but not tie
the database to a particular remote_id or MobiLink User name before you
send it out.

If sending the authentication parameter after the initial
synchronization is an issue, you could define two script versions in the
ML Server, one that uses the authentication parameter, and one that
doesn't. When you app decides it wants to synch, it checks to see
whether time "t2" is stored in the database. If it is, send the
authentication parameter and use script version "shao_withAP". Once
there is a successful synch using this script version, delete time "t2"
from the database. Subsequent synchronizations will detect that time
"t2" doesn't exist in the database, will not define an authentication
parameter, and will use script version "shao", which doesn't require an
authentication parameter.

There are probably other solutions, but this is first one that came to
mind.

--
Reg Domaratzki - Sybase
Please reply only to the newsgroup

Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
SQL Anywhere Patches and EBFs : http://downloads.sybase.com/swd/base.do
-> Choose SQL Anywhere
-> Optionally set filter to "Display ALL platforms IN ALL MONTHS"


Shao Chan Posted on 2011-10-06 14:04:26.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 66
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8db56a$1@forums-1-dub>
Date: 6 Oct 2011 07:04:26 -0700
X-Trace: forums-1-dub 1317909866 10.22.241.152 (6 Oct 2011 07:04:26 -0700)
X-Original-Trace: 6 Oct 2011 07:04:26 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12611
Article PK: 1048394

Hi Reg,

Thanks for the detailed response. I think I'm going to have to give this
one some thought.

Cheers,

Shao

"Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in message
news:4e8dae9e@forums-1-dub...
> Shao, if the data that you are pre-populating into the ULDB is from tables
> that are also synchronize using a timestamp based approach, you'll have
> this problem regardless of how you initially populate the ULDB.
>
> Here's one option:
>
> When you initially populate the database with data at time "t2" (it's
> important to note that time "t2" is the time that you pulled the data from
> the consolidate, and it's the time at the consolidated database), I would
> suggest storing time "t2" in your remote database, possibly in a table
> that doesn't synch. Now, whenever you synchronize, you send up an
> authentication parameter that will tell the MobiLink Server at what time
> the subset of initial data was generated for this remote. You can now
> change your synchronization scripts on tables that included initial data
> to read :
>
> select pk,c1,c2
> from t1
> where last_mod >= max( {ml s.last_table_download}, {ml a.1} )
>
> So, for the initial synch, when {ml s.last_table_download} is '1900-01-01
> 00:00:00.000', the authentication parameter will be used, but in
> subsequent synchs, {ml s.last_table_download} will be greater than {ml
> a.1}.
>
> This does mean that you're sending an authentication parameter that's
> around 20 bytes in size for every synchronization, but it will allow you
> to pre-populate your remote database with some of the data, but not tie
> the database to a particular remote_id or MobiLink User name before you
> send it out.
>
> If sending the authentication parameter after the initial synchronization
> is an issue, you could define two script versions in the ML Server, one
> that uses the authentication parameter, and one that doesn't. When you
> app decides it wants to synch, it checks to see whether time "t2" is
> stored in the database. If it is, send the authentication parameter and
> use script version "shao_withAP". Once there is a successful synch using
> this script version, delete time "t2" from the database. Subsequent
> synchronizations will detect that time "t2" doesn't exist in the database,
> will not define an authentication parameter, and will use script version
> "shao", which doesn't require an authentication parameter.
>
> There are probably other solutions, but this is first one that came to
> mind.
>
> --
> Reg Domaratzki - Sybase
> Please reply only to the newsgroup
>
> Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
> SQL Anywhere Patches and EBFs : http://downloads.sybase.com/swd/base.do
> -> Choose SQL Anywhere
> -> Optionally set filter to "Display ALL platforms IN ALL MONTHS"


Shao Chan Posted on 2011-10-07 09:50:14.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 93
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8ecb56@forums-1-dub>
Date: 7 Oct 2011 02:50:14 -0700
X-Trace: forums-1-dub 1317981014 10.22.241.152 (7 Oct 2011 02:50:14 -0700)
X-Original-Trace: 7 Oct 2011 02:50:14 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12615
Article PK: 1048385

Oh, one other thing everyone at iAnywhere may need to be aware of.....

We have found that users on the O2 network, when doing an initial sync, if
the sync traffic is greater than 3-5Mb (not really sure of the exact
amount), the sync will fail. We try using a T-Mobile or Orange SIM and the
sync will work fine.

It seems that for one reason or another, O2 is stopping large download
syncs. This may be because its TCP traffic that its trapping or something
else.

Anyway, whilst some customers are happy to cradle a device in office to do
the initial sync, others may not. And when moving to other platforms where
cradling a device may not be an option and for security reasons, using a
local WiFi may not be an option either, I do think that iAnywhere exploring
a clean way to do an initial sync without issues of the second user logging
on resulting in the same data coming down a second time may be something
worthwhile.

Cheers,

Shao

"Shao Chan" <nospam@nospam.com> wrote in message
news:4e8db56a$1@forums-1-dub...
> Hi Reg,
>
> Thanks for the detailed response. I think I'm going to have to give this
> one some thought.
>
> Cheers,
>
> Shao
>
> "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in message
> news:4e8dae9e@forums-1-dub...
>> Shao, if the data that you are pre-populating into the ULDB is from
>> tables that are also synchronize using a timestamp based approach, you'll
>> have this problem regardless of how you initially populate the ULDB.
>>
>> Here's one option:
>>
>> When you initially populate the database with data at time "t2" (it's
>> important to note that time "t2" is the time that you pulled the data
>> from the consolidate, and it's the time at the consolidated database), I
>> would suggest storing time "t2" in your remote database, possibly in a
>> table that doesn't synch. Now, whenever you synchronize, you send up an
>> authentication parameter that will tell the MobiLink Server at what time
>> the subset of initial data was generated for this remote. You can now
>> change your synchronization scripts on tables that included initial data
>> to read :
>>
>> select pk,c1,c2
>> from t1
>> where last_mod >= max( {ml s.last_table_download}, {ml a.1} )
>>
>> So, for the initial synch, when {ml s.last_table_download} is '1900-01-01
>> 00:00:00.000', the authentication parameter will be used, but in
>> subsequent synchs, {ml s.last_table_download} will be greater than {ml
>> a.1}.
>>
>> This does mean that you're sending an authentication parameter that's
>> around 20 bytes in size for every synchronization, but it will allow you
>> to pre-populate your remote database with some of the data, but not tie
>> the database to a particular remote_id or MobiLink User name before you
>> send it out.
>>
>> If sending the authentication parameter after the initial synchronization
>> is an issue, you could define two script versions in the ML Server, one
>> that uses the authentication parameter, and one that doesn't. When you
>> app decides it wants to synch, it checks to see whether time "t2" is
>> stored in the database. If it is, send the authentication parameter and
>> use script version "shao_withAP". Once there is a successful synch using
>> this script version, delete time "t2" from the database. Subsequent
>> synchronizations will detect that time "t2" doesn't exist in the
>> database, will not define an authentication parameter, and will use
>> script version "shao", which doesn't require an authentication parameter.
>>
>> There are probably other solutions, but this is first one that came to
>> mind.
>>
>> --
>> Reg Domaratzki - Sybase
>> Please reply only to the newsgroup
>>
>> Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
>> SQL Anywhere Patches and EBFs : http://downloads.sybase.com/swd/base.do
>> -> Choose SQL Anywhere
>> -> Optionally set filter to "Display ALL platforms IN ALL MONTHS"
>
>


Tim McClements [Sybase] Posted on 2011-10-07 19:05:20.0Z
From: "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub> <4e8ecb56@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 108
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8f4d70@forums-1-dub>
Date: 7 Oct 2011 12:05:20 -0700
X-Trace: forums-1-dub 1318014320 10.22.241.152 (7 Oct 2011 12:05:20 -0700)
X-Original-Trace: 7 Oct 2011 12:05:20 -0700, vip152.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12616
Article PK: 1048402

Hi Shao,

Do you know what error you get on the synchronize call in this case?

UL's resumable download feature is designed to handle cases like this...

- Tim

"Shao Chan" <nospam@nospam.com> wrote in message
news:4e8ecb56@forums-1-dub...
> Oh, one other thing everyone at iAnywhere may need to be aware of.....
>
> We have found that users on the O2 network, when doing an initial sync, if
> the sync traffic is greater than 3-5Mb (not really sure of the exact
> amount), the sync will fail. We try using a T-Mobile or Orange SIM and
> the sync will work fine.
>
> It seems that for one reason or another, O2 is stopping large download
> syncs. This may be because its TCP traffic that its trapping or something
> else.
>
> Anyway, whilst some customers are happy to cradle a device in office to do
> the initial sync, others may not. And when moving to other platforms
> where cradling a device may not be an option and for security reasons,
> using a local WiFi may not be an option either, I do think that iAnywhere
> exploring a clean way to do an initial sync without issues of the second
> user logging on resulting in the same data coming down a second time may
> be something worthwhile.
>
> Cheers,
>
> Shao
>
> "Shao Chan" <nospam@nospam.com> wrote in message
> news:4e8db56a$1@forums-1-dub...
>> Hi Reg,
>>
>> Thanks for the detailed response. I think I'm going to have to give this
>> one some thought.
>>
>> Cheers,
>>
>> Shao
>>
>> "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in
>> message news:4e8dae9e@forums-1-dub...
>>> Shao, if the data that you are pre-populating into the ULDB is from
>>> tables that are also synchronize using a timestamp based approach,
>>> you'll have this problem regardless of how you initially populate the
>>> ULDB.
>>>
>>> Here's one option:
>>>
>>> When you initially populate the database with data at time "t2" (it's
>>> important to note that time "t2" is the time that you pulled the data
>>> from the consolidate, and it's the time at the consolidated database), I
>>> would suggest storing time "t2" in your remote database, possibly in a
>>> table that doesn't synch. Now, whenever you synchronize, you send up an
>>> authentication parameter that will tell the MobiLink Server at what time
>>> the subset of initial data was generated for this remote. You can now
>>> change your synchronization scripts on tables that included initial data
>>> to read :
>>>
>>> select pk,c1,c2
>>> from t1
>>> where last_mod >= max( {ml s.last_table_download}, {ml a.1} )
>>>
>>> So, for the initial synch, when {ml s.last_table_download} is
>>> '1900-01-01 00:00:00.000', the authentication parameter will be used,
>>> but in subsequent synchs, {ml s.last_table_download} will be greater
>>> than {ml a.1}.
>>>
>>> This does mean that you're sending an authentication parameter that's
>>> around 20 bytes in size for every synchronization, but it will allow you
>>> to pre-populate your remote database with some of the data, but not tie
>>> the database to a particular remote_id or MobiLink User name before you
>>> send it out.
>>>
>>> If sending the authentication parameter after the initial
>>> synchronization is an issue, you could define two script versions in the
>>> ML Server, one that uses the authentication parameter, and one that
>>> doesn't. When you app decides it wants to synch, it checks to see
>>> whether time "t2" is stored in the database. If it is, send the
>>> authentication parameter and use script version "shao_withAP". Once
>>> there is a successful synch using this script version, delete time "t2"
>>> from the database. Subsequent synchronizations will detect that time
>>> "t2" doesn't exist in the database, will not define an authentication
>>> parameter, and will use script version "shao", which doesn't require an
>>> authentication parameter.
>>>
>>> There are probably other solutions, but this is first one that came to
>>> mind.
>>>
>>> --
>>> Reg Domaratzki - Sybase
>>> Please reply only to the newsgroup
>>>
>>> Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
>>> SQL Anywhere Patches and EBFs : http://downloads.sybase.com/swd/base.do
>>> -> Choose SQL Anywhere
>>> -> Optionally set filter to "Display ALL platforms IN ALL MONTHS"
>>
>>
>
>


Shao Chan Posted on 2011-10-07 22:05:28.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub> <4e8ecb56@forums-1-dub> <4e8f4d70@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 131
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8f77a8$1@forums-1-dub>
Date: 7 Oct 2011 15:05:28 -0700
X-Trace: forums-1-dub 1318025128 10.22.241.152 (7 Oct 2011 15:05:28 -0700)
X-Original-Trace: 7 Oct 2011 15:05:28 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12620
Article PK: 1048409

Hi Tim,

Our application just gets a Synchronisation Failed message.

The problem isn't whether or not the Ultralite is robust enough to handle
it. The problem is that if the O2 network cuts off the transmission after a
certain size, if we are ever in a situation where the client application
needs to rebuild the database, the initial sync is too large for it to work
over the air.

Therefore having a database with the initial sync done with the majority of
reference data means that a new database can always be created within the
application by copying the database that has had the initial sync performed.

Thanks,

Shao

"Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
news:4e8f4d70@forums-1-dub...
> Hi Shao,
>
> Do you know what error you get on the synchronize call in this case?
>
> UL's resumable download feature is designed to handle cases like this...
>
> - Tim
>
>
> "Shao Chan" <nospam@nospam.com> wrote in message
> news:4e8ecb56@forums-1-dub...
>> Oh, one other thing everyone at iAnywhere may need to be aware of.....
>>
>> We have found that users on the O2 network, when doing an initial sync,
>> if the sync traffic is greater than 3-5Mb (not really sure of the exact
>> amount), the sync will fail. We try using a T-Mobile or Orange SIM and
>> the sync will work fine.
>>
>> It seems that for one reason or another, O2 is stopping large download
>> syncs. This may be because its TCP traffic that its trapping or
>> something else.
>>
>> Anyway, whilst some customers are happy to cradle a device in office to
>> do the initial sync, others may not. And when moving to other platforms
>> where cradling a device may not be an option and for security reasons,
>> using a local WiFi may not be an option either, I do think that iAnywhere
>> exploring a clean way to do an initial sync without issues of the second
>> user logging on resulting in the same data coming down a second time may
>> be something worthwhile.
>>
>> Cheers,
>>
>> Shao
>>
>> "Shao Chan" <nospam@nospam.com> wrote in message
>> news:4e8db56a$1@forums-1-dub...
>>> Hi Reg,
>>>
>>> Thanks for the detailed response. I think I'm going to have to give
>>> this one some thought.
>>>
>>> Cheers,
>>>
>>> Shao
>>>
>>> "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in
>>> message news:4e8dae9e@forums-1-dub...
>>>> Shao, if the data that you are pre-populating into the ULDB is from
>>>> tables that are also synchronize using a timestamp based approach,
>>>> you'll have this problem regardless of how you initially populate the
>>>> ULDB.
>>>>
>>>> Here's one option:
>>>>
>>>> When you initially populate the database with data at time "t2" (it's
>>>> important to note that time "t2" is the time that you pulled the data
>>>> from the consolidate, and it's the time at the consolidated database),
>>>> I would suggest storing time "t2" in your remote database, possibly in
>>>> a table that doesn't synch. Now, whenever you synchronize, you send up
>>>> an authentication parameter that will tell the MobiLink Server at what
>>>> time the subset of initial data was generated for this remote. You can
>>>> now change your synchronization scripts on tables that included initial
>>>> data to read :
>>>>
>>>> select pk,c1,c2
>>>> from t1
>>>> where last_mod >= max( {ml s.last_table_download}, {ml a.1} )
>>>>
>>>> So, for the initial synch, when {ml s.last_table_download} is
>>>> '1900-01-01 00:00:00.000', the authentication parameter will be used,
>>>> but in subsequent synchs, {ml s.last_table_download} will be greater
>>>> than {ml a.1}.
>>>>
>>>> This does mean that you're sending an authentication parameter that's
>>>> around 20 bytes in size for every synchronization, but it will allow
>>>> you to pre-populate your remote database with some of the data, but not
>>>> tie the database to a particular remote_id or MobiLink User name before
>>>> you send it out.
>>>>
>>>> If sending the authentication parameter after the initial
>>>> synchronization is an issue, you could define two script versions in
>>>> the ML Server, one that uses the authentication parameter, and one that
>>>> doesn't. When you app decides it wants to synch, it checks to see
>>>> whether time "t2" is stored in the database. If it is, send the
>>>> authentication parameter and use script version "shao_withAP". Once
>>>> there is a successful synch using this script version, delete time "t2"
>>>> from the database. Subsequent synchronizations will detect that time
>>>> "t2" doesn't exist in the database, will not define an authentication
>>>> parameter, and will use script version "shao", which doesn't require an
>>>> authentication parameter.
>>>>
>>>> There are probably other solutions, but this is first one that came to
>>>> mind.
>>>>
>>>> --
>>>> Reg Domaratzki - Sybase
>>>> Please reply only to the newsgroup
>>>>
>>>> Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
>>>> SQL Anywhere Patches and EBFs : http://downloads.sybase.com/swd/base.do
>>>> -> Choose SQL Anywhere
>>>> -> Optionally set filter to "Display ALL platforms IN ALL MONTHS"
>>>
>>>
>>
>>
>
>


Tim McClements [Sybase] Posted on 2011-10-13 16:28:07.0Z
From: "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub> <4e8ecb56@forums-1-dub> <4e8f4d70@forums-1-dub> <4e8f77a8$1@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 151
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e971197@forums-1-dub>
Date: 13 Oct 2011 09:28:07 -0700
X-Trace: forums-1-dub 1318523287 10.22.241.152 (13 Oct 2011 09:28:07 -0700)
X-Original-Trace: 13 Oct 2011 09:28:07 -0700, vip152.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12630
Article PK: 1048425

Hi Shao,

I'm interested in the specific sqlcode and parameters you get after the
failed sync.

The resumable download feature does address this problem, I hope: each time
you synchronize, though it's cut off, you do receive something and progress
is made because the resumable download feature continues from where it left
off on the next sync call. This will work as long as the network allows more
traffic through on subsequent connections. Basically, the feature allows the
download to be received over many shorter sync sessions.

- Tim

"Shao Chan" <nospam@nospam.com> wrote in message
news:4e8f77a8$1@forums-1-dub...
> Hi Tim,
>
> Our application just gets a Synchronisation Failed message.
>
> The problem isn't whether or not the Ultralite is robust enough to handle
> it. The problem is that if the O2 network cuts off the transmission after
> a certain size, if we are ever in a situation where the client application
> needs to rebuild the database, the initial sync is too large for it to
> work over the air.
>
> Therefore having a database with the initial sync done with the majority
> of reference data means that a new database can always be created within
> the application by copying the database that has had the initial sync
> performed.
>
> Thanks,
>
> Shao
>
>
> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
> news:4e8f4d70@forums-1-dub...
>> Hi Shao,
>>
>> Do you know what error you get on the synchronize call in this case?
>>
>> UL's resumable download feature is designed to handle cases like this...
>>
>> - Tim
>>
>>
>> "Shao Chan" <nospam@nospam.com> wrote in message
>> news:4e8ecb56@forums-1-dub...
>>> Oh, one other thing everyone at iAnywhere may need to be aware of.....
>>>
>>> We have found that users on the O2 network, when doing an initial sync,
>>> if the sync traffic is greater than 3-5Mb (not really sure of the exact
>>> amount), the sync will fail. We try using a T-Mobile or Orange SIM and
>>> the sync will work fine.
>>>
>>> It seems that for one reason or another, O2 is stopping large download
>>> syncs. This may be because its TCP traffic that its trapping or
>>> something else.
>>>
>>> Anyway, whilst some customers are happy to cradle a device in office to
>>> do the initial sync, others may not. And when moving to other platforms
>>> where cradling a device may not be an option and for security reasons,
>>> using a local WiFi may not be an option either, I do think that
>>> iAnywhere exploring a clean way to do an initial sync without issues of
>>> the second user logging on resulting in the same data coming down a
>>> second time may be something worthwhile.
>>>
>>> Cheers,
>>>
>>> Shao
>>>
>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>> news:4e8db56a$1@forums-1-dub...
>>>> Hi Reg,
>>>>
>>>> Thanks for the detailed response. I think I'm going to have to give
>>>> this one some thought.
>>>>
>>>> Cheers,
>>>>
>>>> Shao
>>>>
>>>> "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in
>>>> message news:4e8dae9e@forums-1-dub...
>>>>> Shao, if the data that you are pre-populating into the ULDB is from
>>>>> tables that are also synchronize using a timestamp based approach,
>>>>> you'll have this problem regardless of how you initially populate the
>>>>> ULDB.
>>>>>
>>>>> Here's one option:
>>>>>
>>>>> When you initially populate the database with data at time "t2" (it's
>>>>> important to note that time "t2" is the time that you pulled the data
>>>>> from the consolidate, and it's the time at the consolidated database),
>>>>> I would suggest storing time "t2" in your remote database, possibly in
>>>>> a table that doesn't synch. Now, whenever you synchronize, you send
>>>>> up an authentication parameter that will tell the MobiLink Server at
>>>>> what time the subset of initial data was generated for this remote.
>>>>> You can now change your synchronization scripts on tables that
>>>>> included initial data to read :
>>>>>
>>>>> select pk,c1,c2
>>>>> from t1
>>>>> where last_mod >= max( {ml s.last_table_download}, {ml a.1} )
>>>>>
>>>>> So, for the initial synch, when {ml s.last_table_download} is
>>>>> '1900-01-01 00:00:00.000', the authentication parameter will be used,
>>>>> but in subsequent synchs, {ml s.last_table_download} will be greater
>>>>> than {ml a.1}.
>>>>>
>>>>> This does mean that you're sending an authentication parameter that's
>>>>> around 20 bytes in size for every synchronization, but it will allow
>>>>> you to pre-populate your remote database with some of the data, but
>>>>> not tie the database to a particular remote_id or MobiLink User name
>>>>> before you send it out.
>>>>>
>>>>> If sending the authentication parameter after the initial
>>>>> synchronization is an issue, you could define two script versions in
>>>>> the ML Server, one that uses the authentication parameter, and one
>>>>> that doesn't. When you app decides it wants to synch, it checks to
>>>>> see whether time "t2" is stored in the database. If it is, send the
>>>>> authentication parameter and use script version "shao_withAP". Once
>>>>> there is a successful synch using this script version, delete time
>>>>> "t2" from the database. Subsequent synchronizations will detect that
>>>>> time "t2" doesn't exist in the database, will not define an
>>>>> authentication parameter, and will use script version "shao", which
>>>>> doesn't require an authentication parameter.
>>>>>
>>>>> There are probably other solutions, but this is first one that came to
>>>>> mind.
>>>>>
>>>>> --
>>>>> Reg Domaratzki - Sybase
>>>>> Please reply only to the newsgroup
>>>>>
>>>>> Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
>>>>> SQL Anywhere Patches and EBFs :
>>>>> http://downloads.sybase.com/swd/base.do
>>>>> -> Choose SQL Anywhere
>>>>> -> Optionally set filter to "Display ALL platforms IN ALL MONTHS"
>>>>
>>>>
>>>
>>>
>>
>>
>
>


Shao Chan Posted on 2011-10-13 22:59:00.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub> <4e8ecb56@forums-1-dub> <4e8f4d70@forums-1-dub> <4e8f77a8$1@forums-1-dub> <4e971197@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 168
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e976d34@forums-1-dub>
Date: 13 Oct 2011 15:59:00 -0700
X-Trace: forums-1-dub 1318546740 10.22.241.152 (13 Oct 2011 15:59:00 -0700)
X-Original-Trace: 13 Oct 2011 15:59:00 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12633
Article PK: 1048426

Hi Tim,

Does this resume feature exist in 9.0.2.latest.ebf? It's this version that
we have the problem.

We haven't gone live with 12.0.1. yet.

Thanks,

Shao

"Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
news:4e971197@forums-1-dub...
> Hi Shao,
>
> I'm interested in the specific sqlcode and parameters you get after the
> failed sync.
>
> The resumable download feature does address this problem, I hope: each
> time you synchronize, though it's cut off, you do receive something and
> progress is made because the resumable download feature continues from
> where it left off on the next sync call. This will work as long as the
> network allows more traffic through on subsequent connections. Basically,
> the feature allows the download to be received over many shorter sync
> sessions.
>
> - Tim
>
> "Shao Chan" <nospam@nospam.com> wrote in message
> news:4e8f77a8$1@forums-1-dub...
>> Hi Tim,
>>
>> Our application just gets a Synchronisation Failed message.
>>
>> The problem isn't whether or not the Ultralite is robust enough to handle
>> it. The problem is that if the O2 network cuts off the transmission
>> after a certain size, if we are ever in a situation where the client
>> application needs to rebuild the database, the initial sync is too large
>> for it to work over the air.
>>
>> Therefore having a database with the initial sync done with the majority
>> of reference data means that a new database can always be created within
>> the application by copying the database that has had the initial sync
>> performed.
>>
>> Thanks,
>>
>> Shao
>>
>>
>> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
>> news:4e8f4d70@forums-1-dub...
>>> Hi Shao,
>>>
>>> Do you know what error you get on the synchronize call in this case?
>>>
>>> UL's resumable download feature is designed to handle cases like this...
>>>
>>> - Tim
>>>
>>>
>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>> news:4e8ecb56@forums-1-dub...
>>>> Oh, one other thing everyone at iAnywhere may need to be aware of.....
>>>>
>>>> We have found that users on the O2 network, when doing an initial sync,
>>>> if the sync traffic is greater than 3-5Mb (not really sure of the exact
>>>> amount), the sync will fail. We try using a T-Mobile or Orange SIM and
>>>> the sync will work fine.
>>>>
>>>> It seems that for one reason or another, O2 is stopping large download
>>>> syncs. This may be because its TCP traffic that its trapping or
>>>> something else.
>>>>
>>>> Anyway, whilst some customers are happy to cradle a device in office to
>>>> do the initial sync, others may not. And when moving to other
>>>> platforms where cradling a device may not be an option and for security
>>>> reasons, using a local WiFi may not be an option either, I do think
>>>> that iAnywhere exploring a clean way to do an initial sync without
>>>> issues of the second user logging on resulting in the same data coming
>>>> down a second time may be something worthwhile.
>>>>
>>>> Cheers,
>>>>
>>>> Shao
>>>>
>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>> news:4e8db56a$1@forums-1-dub...
>>>>> Hi Reg,
>>>>>
>>>>> Thanks for the detailed response. I think I'm going to have to give
>>>>> this one some thought.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Shao
>>>>>
>>>>> "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in
>>>>> message news:4e8dae9e@forums-1-dub...
>>>>>> Shao, if the data that you are pre-populating into the ULDB is from
>>>>>> tables that are also synchronize using a timestamp based approach,
>>>>>> you'll have this problem regardless of how you initially populate the
>>>>>> ULDB.
>>>>>>
>>>>>> Here's one option:
>>>>>>
>>>>>> When you initially populate the database with data at time "t2" (it's
>>>>>> important to note that time "t2" is the time that you pulled the data
>>>>>> from the consolidate, and it's the time at the consolidated
>>>>>> database), I would suggest storing time "t2" in your remote database,
>>>>>> possibly in a table that doesn't synch. Now, whenever you
>>>>>> synchronize, you send up an authentication parameter that will tell
>>>>>> the MobiLink Server at what time the subset of initial data was
>>>>>> generated for this remote. You can now change your synchronization
>>>>>> scripts on tables that included initial data to read :
>>>>>>
>>>>>> select pk,c1,c2
>>>>>> from t1
>>>>>> where last_mod >= max( {ml s.last_table_download}, {ml a.1} )
>>>>>>
>>>>>> So, for the initial synch, when {ml s.last_table_download} is
>>>>>> '1900-01-01 00:00:00.000', the authentication parameter will be used,
>>>>>> but in subsequent synchs, {ml s.last_table_download} will be greater
>>>>>> than {ml a.1}.
>>>>>>
>>>>>> This does mean that you're sending an authentication parameter that's
>>>>>> around 20 bytes in size for every synchronization, but it will allow
>>>>>> you to pre-populate your remote database with some of the data, but
>>>>>> not tie the database to a particular remote_id or MobiLink User name
>>>>>> before you send it out.
>>>>>>
>>>>>> If sending the authentication parameter after the initial
>>>>>> synchronization is an issue, you could define two script versions in
>>>>>> the ML Server, one that uses the authentication parameter, and one
>>>>>> that doesn't. When you app decides it wants to synch, it checks to
>>>>>> see whether time "t2" is stored in the database. If it is, send the
>>>>>> authentication parameter and use script version "shao_withAP". Once
>>>>>> there is a successful synch using this script version, delete time
>>>>>> "t2" from the database. Subsequent synchronizations will detect that
>>>>>> time "t2" doesn't exist in the database, will not define an
>>>>>> authentication parameter, and will use script version "shao", which
>>>>>> doesn't require an authentication parameter.
>>>>>>
>>>>>> There are probably other solutions, but this is first one that came
>>>>>> to mind.
>>>>>>
>>>>>> --
>>>>>> Reg Domaratzki - Sybase
>>>>>> Please reply only to the newsgroup
>>>>>>
>>>>>> Documentation : Exercise your WRITE @DocCommentXchange:
>>>>>> DCX.sybase.com
>>>>>> SQL Anywhere Patches and EBFs :
>>>>>> http://downloads.sybase.com/swd/base.do
>>>>>> -> Choose SQL Anywhere
>>>>>> -> Optionally set filter to "Display ALL platforms IN ALL MONTHS"
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


Tim McClements [Sybase] Posted on 2011-10-14 18:45:31.0Z
From: "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub> <4e8ecb56@forums-1-dub> <4e8f4d70@forums-1-dub> <4e8f77a8$1@forums-1-dub> <4e971197@forums-1-dub> <4e976d34@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 180
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e98834b$1@forums-1-dub>
Date: 14 Oct 2011 11:45:31 -0700
X-Trace: forums-1-dub 1318617931 10.22.241.152 (14 Oct 2011 11:45:31 -0700)
X-Original-Trace: 14 Oct 2011 11:45:31 -0700, vip152.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12636
Article PK: 1048397

Hi Shao,

Yes, it's in the C API in 9.0.2... the ul_synch_info structure has
'keep_partial_download' and 'resume_partial_download' fields...

- Tim

"Shao Chan" <nospam@nospam.com> wrote in message
news:4e976d34@forums-1-dub...
> Hi Tim,
>
> Does this resume feature exist in 9.0.2.latest.ebf? It's this version
> that we have the problem.
>
> We haven't gone live with 12.0.1. yet.
>
> Thanks,
>
> Shao
>
> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
> news:4e971197@forums-1-dub...
>> Hi Shao,
>>
>> I'm interested in the specific sqlcode and parameters you get after the
>> failed sync.
>>
>> The resumable download feature does address this problem, I hope: each
>> time you synchronize, though it's cut off, you do receive something and
>> progress is made because the resumable download feature continues from
>> where it left off on the next sync call. This will work as long as the
>> network allows more traffic through on subsequent connections. Basically,
>> the feature allows the download to be received over many shorter sync
>> sessions.
>>
>> - Tim
>>
>> "Shao Chan" <nospam@nospam.com> wrote in message
>> news:4e8f77a8$1@forums-1-dub...
>>> Hi Tim,
>>>
>>> Our application just gets a Synchronisation Failed message.
>>>
>>> The problem isn't whether or not the Ultralite is robust enough to
>>> handle it. The problem is that if the O2 network cuts off the
>>> transmission after a certain size, if we are ever in a situation where
>>> the client application needs to rebuild the database, the initial sync
>>> is too large for it to work over the air.
>>>
>>> Therefore having a database with the initial sync done with the majority
>>> of reference data means that a new database can always be created within
>>> the application by copying the database that has had the initial sync
>>> performed.
>>>
>>> Thanks,
>>>
>>> Shao
>>>
>>>
>>> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
>>> news:4e8f4d70@forums-1-dub...
>>>> Hi Shao,
>>>>
>>>> Do you know what error you get on the synchronize call in this case?
>>>>
>>>> UL's resumable download feature is designed to handle cases like
>>>> this...
>>>>
>>>> - Tim
>>>>
>>>>
>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>> news:4e8ecb56@forums-1-dub...
>>>>> Oh, one other thing everyone at iAnywhere may need to be aware of.....
>>>>>
>>>>> We have found that users on the O2 network, when doing an initial
>>>>> sync, if the sync traffic is greater than 3-5Mb (not really sure of
>>>>> the exact amount), the sync will fail. We try using a T-Mobile or
>>>>> Orange SIM and the sync will work fine.
>>>>>
>>>>> It seems that for one reason or another, O2 is stopping large download
>>>>> syncs. This may be because its TCP traffic that its trapping or
>>>>> something else.
>>>>>
>>>>> Anyway, whilst some customers are happy to cradle a device in office
>>>>> to do the initial sync, others may not. And when moving to other
>>>>> platforms where cradling a device may not be an option and for
>>>>> security reasons, using a local WiFi may not be an option either, I do
>>>>> think that iAnywhere exploring a clean way to do an initial sync
>>>>> without issues of the second user logging on resulting in the same
>>>>> data coming down a second time may be something worthwhile.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Shao
>>>>>
>>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>>> news:4e8db56a$1@forums-1-dub...
>>>>>> Hi Reg,
>>>>>>
>>>>>> Thanks for the detailed response. I think I'm going to have to give
>>>>>> this one some thought.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Shao
>>>>>>
>>>>>> "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in
>>>>>> message news:4e8dae9e@forums-1-dub...
>>>>>>> Shao, if the data that you are pre-populating into the ULDB is from
>>>>>>> tables that are also synchronize using a timestamp based approach,
>>>>>>> you'll have this problem regardless of how you initially populate
>>>>>>> the ULDB.
>>>>>>>
>>>>>>> Here's one option:
>>>>>>>
>>>>>>> When you initially populate the database with data at time "t2"
>>>>>>> (it's important to note that time "t2" is the time that you pulled
>>>>>>> the data from the consolidate, and it's the time at the consolidated
>>>>>>> database), I would suggest storing time "t2" in your remote
>>>>>>> database, possibly in a table that doesn't synch. Now, whenever you
>>>>>>> synchronize, you send up an authentication parameter that will tell
>>>>>>> the MobiLink Server at what time the subset of initial data was
>>>>>>> generated for this remote. You can now change your synchronization
>>>>>>> scripts on tables that included initial data to read :
>>>>>>>
>>>>>>> select pk,c1,c2
>>>>>>> from t1
>>>>>>> where last_mod >= max( {ml s.last_table_download}, {ml a.1} )
>>>>>>>
>>>>>>> So, for the initial synch, when {ml s.last_table_download} is
>>>>>>> '1900-01-01 00:00:00.000', the authentication parameter will be
>>>>>>> used, but in subsequent synchs, {ml s.last_table_download} will be
>>>>>>> greater than {ml a.1}.
>>>>>>>
>>>>>>> This does mean that you're sending an authentication parameter
>>>>>>> that's around 20 bytes in size for every synchronization, but it
>>>>>>> will allow you to pre-populate your remote database with some of the
>>>>>>> data, but not tie the database to a particular remote_id or MobiLink
>>>>>>> User name before you send it out.
>>>>>>>
>>>>>>> If sending the authentication parameter after the initial
>>>>>>> synchronization is an issue, you could define two script versions in
>>>>>>> the ML Server, one that uses the authentication parameter, and one
>>>>>>> that doesn't. When you app decides it wants to synch, it checks to
>>>>>>> see whether time "t2" is stored in the database. If it is, send the
>>>>>>> authentication parameter and use script version "shao_withAP". Once
>>>>>>> there is a successful synch using this script version, delete time
>>>>>>> "t2" from the database. Subsequent synchronizations will detect
>>>>>>> that time "t2" doesn't exist in the database, will not define an
>>>>>>> authentication parameter, and will use script version "shao", which
>>>>>>> doesn't require an authentication parameter.
>>>>>>>
>>>>>>> There are probably other solutions, but this is first one that came
>>>>>>> to mind.
>>>>>>>
>>>>>>> --
>>>>>>> Reg Domaratzki - Sybase
>>>>>>> Please reply only to the newsgroup
>>>>>>>
>>>>>>> Documentation : Exercise your WRITE @DocCommentXchange:
>>>>>>> DCX.sybase.com
>>>>>>> SQL Anywhere Patches and EBFs :
>>>>>>> http://downloads.sybase.com/swd/base.do
>>>>>>> -> Choose SQL Anywhere
>>>>>>> -> Optionally set filter to "Display ALL platforms IN ALL MONTHS"
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


Shao Chan Posted on 2011-10-17 12:32:42.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub> <4e8ecb56@forums-1-dub> <4e8f4d70@forums-1-dub> <4e8f77a8$1@forums-1-dub> <4e971197@forums-1-dub> <4e976d34@forums-1-dub> <4e98834b$1@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 206
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e9c206a@forums-1-dub>
Date: 17 Oct 2011 05:32:42 -0700
X-Trace: forums-1-dub 1318854762 10.22.241.152 (17 Oct 2011 05:32:42 -0700)
X-Original-Trace: 17 Oct 2011 05:32:42 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12637
Article PK: 1048410

Hi Tim,

Does this work if its the first time the engineer is logging into the remote
database? It's the first sync that has the large download and failed sync.

Is there anything specific I have to show from the error messages, e.g.
conn.syncResult.getAuthStatus();
conn.syncResult.getStreamErrorCode();
conn.syncResult.getStreamErrorConext();
conn.syncResult.getStreamErrorSystem();

At the moment, I just purge the user's data in the middle-tier mobile ASA
database so that their sync is a lot smaller.

Cheers,

Shao

"Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
news:4e98834b$1@forums-1-dub...
> Hi Shao,
>
> Yes, it's in the C API in 9.0.2... the ul_synch_info structure has
> 'keep_partial_download' and 'resume_partial_download' fields...
>
> - Tim
>
> "Shao Chan" <nospam@nospam.com> wrote in message
> news:4e976d34@forums-1-dub...
>> Hi Tim,
>>
>> Does this resume feature exist in 9.0.2.latest.ebf? It's this version
>> that we have the problem.
>>
>> We haven't gone live with 12.0.1. yet.
>>
>> Thanks,
>>
>> Shao
>>
>> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
>> news:4e971197@forums-1-dub...
>>> Hi Shao,
>>>
>>> I'm interested in the specific sqlcode and parameters you get after the
>>> failed sync.
>>>
>>> The resumable download feature does address this problem, I hope: each
>>> time you synchronize, though it's cut off, you do receive something and
>>> progress is made because the resumable download feature continues from
>>> where it left off on the next sync call. This will work as long as the
>>> network allows more traffic through on subsequent connections.
>>> Basically, the feature allows the download to be received over many
>>> shorter sync sessions.
>>>
>>> - Tim
>>>
>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>> news:4e8f77a8$1@forums-1-dub...
>>>> Hi Tim,
>>>>
>>>> Our application just gets a Synchronisation Failed message.
>>>>
>>>> The problem isn't whether or not the Ultralite is robust enough to
>>>> handle it. The problem is that if the O2 network cuts off the
>>>> transmission after a certain size, if we are ever in a situation where
>>>> the client application needs to rebuild the database, the initial sync
>>>> is too large for it to work over the air.
>>>>
>>>> Therefore having a database with the initial sync done with the
>>>> majority of reference data means that a new database can always be
>>>> created within the application by copying the database that has had the
>>>> initial sync performed.
>>>>
>>>> Thanks,
>>>>
>>>> Shao
>>>>
>>>>
>>>> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
>>>> news:4e8f4d70@forums-1-dub...
>>>>> Hi Shao,
>>>>>
>>>>> Do you know what error you get on the synchronize call in this case?
>>>>>
>>>>> UL's resumable download feature is designed to handle cases like
>>>>> this...
>>>>>
>>>>> - Tim
>>>>>
>>>>>
>>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>>> news:4e8ecb56@forums-1-dub...
>>>>>> Oh, one other thing everyone at iAnywhere may need to be aware
>>>>>> of.....
>>>>>>
>>>>>> We have found that users on the O2 network, when doing an initial
>>>>>> sync, if the sync traffic is greater than 3-5Mb (not really sure of
>>>>>> the exact amount), the sync will fail. We try using a T-Mobile or
>>>>>> Orange SIM and the sync will work fine.
>>>>>>
>>>>>> It seems that for one reason or another, O2 is stopping large
>>>>>> download syncs. This may be because its TCP traffic that its
>>>>>> trapping or something else.
>>>>>>
>>>>>> Anyway, whilst some customers are happy to cradle a device in office
>>>>>> to do the initial sync, others may not. And when moving to other
>>>>>> platforms where cradling a device may not be an option and for
>>>>>> security reasons, using a local WiFi may not be an option either, I
>>>>>> do think that iAnywhere exploring a clean way to do an initial sync
>>>>>> without issues of the second user logging on resulting in the same
>>>>>> data coming down a second time may be something worthwhile.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Shao
>>>>>>
>>>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>>>> news:4e8db56a$1@forums-1-dub...
>>>>>>> Hi Reg,
>>>>>>>
>>>>>>> Thanks for the detailed response. I think I'm going to have to give
>>>>>>> this one some thought.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Shao
>>>>>>>
>>>>>>> "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in
>>>>>>> message news:4e8dae9e@forums-1-dub...
>>>>>>>> Shao, if the data that you are pre-populating into the ULDB is from
>>>>>>>> tables that are also synchronize using a timestamp based approach,
>>>>>>>> you'll have this problem regardless of how you initially populate
>>>>>>>> the ULDB.
>>>>>>>>
>>>>>>>> Here's one option:
>>>>>>>>
>>>>>>>> When you initially populate the database with data at time "t2"
>>>>>>>> (it's important to note that time "t2" is the time that you pulled
>>>>>>>> the data from the consolidate, and it's the time at the
>>>>>>>> consolidated database), I would suggest storing time "t2" in your
>>>>>>>> remote database, possibly in a table that doesn't synch. Now,
>>>>>>>> whenever you synchronize, you send up an authentication parameter
>>>>>>>> that will tell the MobiLink Server at what time the subset of
>>>>>>>> initial data was generated for this remote. You can now change your
>>>>>>>> synchronization scripts on tables that included initial data to
>>>>>>>> read :
>>>>>>>>
>>>>>>>> select pk,c1,c2
>>>>>>>> from t1
>>>>>>>> where last_mod >= max( {ml s.last_table_download}, {ml a.1} )
>>>>>>>>
>>>>>>>> So, for the initial synch, when {ml s.last_table_download} is
>>>>>>>> '1900-01-01 00:00:00.000', the authentication parameter will be
>>>>>>>> used, but in subsequent synchs, {ml s.last_table_download} will be
>>>>>>>> greater than {ml a.1}.
>>>>>>>>
>>>>>>>> This does mean that you're sending an authentication parameter
>>>>>>>> that's around 20 bytes in size for every synchronization, but it
>>>>>>>> will allow you to pre-populate your remote database with some of
>>>>>>>> the data, but not tie the database to a particular remote_id or
>>>>>>>> MobiLink User name before you send it out.
>>>>>>>>
>>>>>>>> If sending the authentication parameter after the initial
>>>>>>>> synchronization is an issue, you could define two script versions
>>>>>>>> in the ML Server, one that uses the authentication parameter, and
>>>>>>>> one that doesn't. When you app decides it wants to synch, it
>>>>>>>> checks to see whether time "t2" is stored in the database. If it
>>>>>>>> is, send the authentication parameter and use script version
>>>>>>>> "shao_withAP". Once there is a successful synch using this script
>>>>>>>> version, delete time "t2" from the database. Subsequent
>>>>>>>> synchronizations will detect that time "t2" doesn't exist in the
>>>>>>>> database, will not define an authentication parameter, and will use
>>>>>>>> script version "shao", which doesn't require an authentication
>>>>>>>> parameter.
>>>>>>>>
>>>>>>>> There are probably other solutions, but this is first one that came
>>>>>>>> to mind.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Reg Domaratzki - Sybase
>>>>>>>> Please reply only to the newsgroup
>>>>>>>>
>>>>>>>> Documentation : Exercise your WRITE @DocCommentXchange:
>>>>>>>> DCX.sybase.com
>>>>>>>> SQL Anywhere Patches and EBFs :
>>>>>>>> http://downloads.sybase.com/swd/base.do
>>>>>>>> -> Choose SQL Anywhere
>>>>>>>> -> Optionally set filter to "Display ALL platforms IN ALL
>>>>>>>> MONTHS"
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


Tim McClements [Sybase] Posted on 2011-10-20 18:24:47.0Z
From: "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub> <4e8ecb56@forums-1-dub> <4e8f4d70@forums-1-dub> <4e8f77a8$1@forums-1-dub> <4e971197@forums-1-dub> <4e976d34@forums-1-dub> <4e98834b$1@forums-1-dub> <4e9c206a@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 220
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4ea0676f$1@forums-1-dub>
Date: 20 Oct 2011 11:24:47 -0700
X-Trace: forums-1-dub 1319135087 10.22.241.152 (20 Oct 2011 11:24:47 -0700)
X-Original-Trace: 20 Oct 2011 11:24:47 -0700, vip152.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12638
Article PK: 1048411

Yes, resumable-downloads should work on any sync.

Are you asking about what error info I wanted to see from the case where O2
cut off the connection? Yes, the SQLCODE and the three stream error values
you list below would be good.

- Tim

"Shao Chan" <nospam@nospam.com> wrote in message
news:4e9c206a@forums-1-dub...
> Hi Tim,
>
> Does this work if its the first time the engineer is logging into the
> remote database? It's the first sync that has the large download and
> failed sync.
>
> Is there anything specific I have to show from the error messages, e.g.
> conn.syncResult.getAuthStatus();
> conn.syncResult.getStreamErrorCode();
> conn.syncResult.getStreamErrorConext();
> conn.syncResult.getStreamErrorSystem();
>
> At the moment, I just purge the user's data in the middle-tier mobile ASA
> database so that their sync is a lot smaller.
>
> Cheers,
>
> Shao
>
> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
> news:4e98834b$1@forums-1-dub...
>> Hi Shao,
>>
>> Yes, it's in the C API in 9.0.2... the ul_synch_info structure has
>> 'keep_partial_download' and 'resume_partial_download' fields...
>>
>> - Tim
>>
>> "Shao Chan" <nospam@nospam.com> wrote in message
>> news:4e976d34@forums-1-dub...
>>> Hi Tim,
>>>
>>> Does this resume feature exist in 9.0.2.latest.ebf? It's this version
>>> that we have the problem.
>>>
>>> We haven't gone live with 12.0.1. yet.
>>>
>>> Thanks,
>>>
>>> Shao
>>>
>>> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
>>> news:4e971197@forums-1-dub...
>>>> Hi Shao,
>>>>
>>>> I'm interested in the specific sqlcode and parameters you get after the
>>>> failed sync.
>>>>
>>>> The resumable download feature does address this problem, I hope: each
>>>> time you synchronize, though it's cut off, you do receive something and
>>>> progress is made because the resumable download feature continues from
>>>> where it left off on the next sync call. This will work as long as the
>>>> network allows more traffic through on subsequent connections.
>>>> Basically, the feature allows the download to be received over many
>>>> shorter sync sessions.
>>>>
>>>> - Tim
>>>>
>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>> news:4e8f77a8$1@forums-1-dub...
>>>>> Hi Tim,
>>>>>
>>>>> Our application just gets a Synchronisation Failed message.
>>>>>
>>>>> The problem isn't whether or not the Ultralite is robust enough to
>>>>> handle it. The problem is that if the O2 network cuts off the
>>>>> transmission after a certain size, if we are ever in a situation where
>>>>> the client application needs to rebuild the database, the initial sync
>>>>> is too large for it to work over the air.
>>>>>
>>>>> Therefore having a database with the initial sync done with the
>>>>> majority of reference data means that a new database can always be
>>>>> created within the application by copying the database that has had
>>>>> the initial sync performed.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Shao
>>>>>
>>>>>
>>>>> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in
>>>>> message news:4e8f4d70@forums-1-dub...
>>>>>> Hi Shao,
>>>>>>
>>>>>> Do you know what error you get on the synchronize call in this case?
>>>>>>
>>>>>> UL's resumable download feature is designed to handle cases like
>>>>>> this...
>>>>>>
>>>>>> - Tim
>>>>>>
>>>>>>
>>>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>>>> news:4e8ecb56@forums-1-dub...
>>>>>>> Oh, one other thing everyone at iAnywhere may need to be aware
>>>>>>> of.....
>>>>>>>
>>>>>>> We have found that users on the O2 network, when doing an initial
>>>>>>> sync, if the sync traffic is greater than 3-5Mb (not really sure of
>>>>>>> the exact amount), the sync will fail. We try using a T-Mobile or
>>>>>>> Orange SIM and the sync will work fine.
>>>>>>>
>>>>>>> It seems that for one reason or another, O2 is stopping large
>>>>>>> download syncs. This may be because its TCP traffic that its
>>>>>>> trapping or something else.
>>>>>>>
>>>>>>> Anyway, whilst some customers are happy to cradle a device in office
>>>>>>> to do the initial sync, others may not. And when moving to other
>>>>>>> platforms where cradling a device may not be an option and for
>>>>>>> security reasons, using a local WiFi may not be an option either, I
>>>>>>> do think that iAnywhere exploring a clean way to do an initial sync
>>>>>>> without issues of the second user logging on resulting in the same
>>>>>>> data coming down a second time may be something worthwhile.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Shao
>>>>>>>
>>>>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>>>>> news:4e8db56a$1@forums-1-dub...
>>>>>>>> Hi Reg,
>>>>>>>>
>>>>>>>> Thanks for the detailed response. I think I'm going to have to
>>>>>>>> give this one some thought.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Shao
>>>>>>>>
>>>>>>>> "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in
>>>>>>>> message news:4e8dae9e@forums-1-dub...
>>>>>>>>> Shao, if the data that you are pre-populating into the ULDB is
>>>>>>>>> from tables that are also synchronize using a timestamp based
>>>>>>>>> approach, you'll have this problem regardless of how you initially
>>>>>>>>> populate the ULDB.
>>>>>>>>>
>>>>>>>>> Here's one option:
>>>>>>>>>
>>>>>>>>> When you initially populate the database with data at time "t2"
>>>>>>>>> (it's important to note that time "t2" is the time that you pulled
>>>>>>>>> the data from the consolidate, and it's the time at the
>>>>>>>>> consolidated database), I would suggest storing time "t2" in your
>>>>>>>>> remote database, possibly in a table that doesn't synch. Now,
>>>>>>>>> whenever you synchronize, you send up an authentication parameter
>>>>>>>>> that will tell the MobiLink Server at what time the subset of
>>>>>>>>> initial data was generated for this remote. You can now change
>>>>>>>>> your synchronization scripts on tables that included initial data
>>>>>>>>> to read :
>>>>>>>>>
>>>>>>>>> select pk,c1,c2
>>>>>>>>> from t1
>>>>>>>>> where last_mod >= max( {ml s.last_table_download}, {ml a.1} )
>>>>>>>>>
>>>>>>>>> So, for the initial synch, when {ml s.last_table_download} is
>>>>>>>>> '1900-01-01 00:00:00.000', the authentication parameter will be
>>>>>>>>> used, but in subsequent synchs, {ml s.last_table_download} will be
>>>>>>>>> greater than {ml a.1}.
>>>>>>>>>
>>>>>>>>> This does mean that you're sending an authentication parameter
>>>>>>>>> that's around 20 bytes in size for every synchronization, but it
>>>>>>>>> will allow you to pre-populate your remote database with some of
>>>>>>>>> the data, but not tie the database to a particular remote_id or
>>>>>>>>> MobiLink User name before you send it out.
>>>>>>>>>
>>>>>>>>> If sending the authentication parameter after the initial
>>>>>>>>> synchronization is an issue, you could define two script versions
>>>>>>>>> in the ML Server, one that uses the authentication parameter, and
>>>>>>>>> one that doesn't. When you app decides it wants to synch, it
>>>>>>>>> checks to see whether time "t2" is stored in the database. If it
>>>>>>>>> is, send the authentication parameter and use script version
>>>>>>>>> "shao_withAP". Once there is a successful synch using this script
>>>>>>>>> version, delete time "t2" from the database. Subsequent
>>>>>>>>> synchronizations will detect that time "t2" doesn't exist in the
>>>>>>>>> database, will not define an authentication parameter, and will
>>>>>>>>> use script version "shao", which doesn't require an authentication
>>>>>>>>> parameter.
>>>>>>>>>
>>>>>>>>> There are probably other solutions, but this is first one that
>>>>>>>>> came to mind.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Reg Domaratzki - Sybase
>>>>>>>>> Please reply only to the newsgroup
>>>>>>>>>
>>>>>>>>> Documentation : Exercise your WRITE @DocCommentXchange:
>>>>>>>>> DCX.sybase.com
>>>>>>>>> SQL Anywhere Patches and EBFs :
>>>>>>>>> http://downloads.sybase.com/swd/base.do
>>>>>>>>> -> Choose SQL Anywhere
>>>>>>>>> -> Optionally set filter to "Display ALL platforms IN ALL
>>>>>>>>> MONTHS"
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


Shao Chan Posted on 2011-10-21 07:10:54.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub> <4e8ecb56@forums-1-dub> <4e8f4d70@forums-1-dub> <4e8f77a8$1@forums-1-dub> <4e971197@forums-1-dub> <4e976d34@forums-1-dub> <4e98834b$1@forums-1-dub> <4e9c206a@forums-1-dub> <4ea0676f$1@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 242
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4ea11afe@forums-1-dub>
Date: 21 Oct 2011 00:10:54 -0700
X-Trace: forums-1-dub 1319181054 10.22.241.152 (21 Oct 2011 00:10:54 -0700)
X-Original-Trace: 21 Oct 2011 00:10:54 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12639
Article PK: 1048407

Hi Tim,

Thanks for that. Yes, that was what I was asking for in case there were
other methods I could call to get specifically what you want.

With all the users at the customer site that have had this problem, we've
gone through a purging process of the system so that initial database sync
is under 2Mb and so I am currently unable to replicate the issue.

However, over time, and if we haven't moved this product to SQLA 12.0.1.
yet, the problem happens again I'll post back.

Thanks,

Shao

"Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
news:4ea0676f$1@forums-1-dub...
> Yes, resumable-downloads should work on any sync.
>
> Are you asking about what error info I wanted to see from the case where
> O2 cut off the connection? Yes, the SQLCODE and the three stream error
> values you list below would be good.
>
> - Tim
>
>
> "Shao Chan" <nospam@nospam.com> wrote in message
> news:4e9c206a@forums-1-dub...
>> Hi Tim,
>>
>> Does this work if its the first time the engineer is logging into the
>> remote database? It's the first sync that has the large download and
>> failed sync.
>>
>> Is there anything specific I have to show from the error messages, e.g.
>> conn.syncResult.getAuthStatus();
>> conn.syncResult.getStreamErrorCode();
>> conn.syncResult.getStreamErrorConext();
>> conn.syncResult.getStreamErrorSystem();
>>
>> At the moment, I just purge the user's data in the middle-tier mobile ASA
>> database so that their sync is a lot smaller.
>>
>> Cheers,
>>
>> Shao
>>
>> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
>> news:4e98834b$1@forums-1-dub...
>>> Hi Shao,
>>>
>>> Yes, it's in the C API in 9.0.2... the ul_synch_info structure has
>>> 'keep_partial_download' and 'resume_partial_download' fields...
>>>
>>> - Tim
>>>
>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>> news:4e976d34@forums-1-dub...
>>>> Hi Tim,
>>>>
>>>> Does this resume feature exist in 9.0.2.latest.ebf? It's this version
>>>> that we have the problem.
>>>>
>>>> We haven't gone live with 12.0.1. yet.
>>>>
>>>> Thanks,
>>>>
>>>> Shao
>>>>
>>>> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
>>>> news:4e971197@forums-1-dub...
>>>>> Hi Shao,
>>>>>
>>>>> I'm interested in the specific sqlcode and parameters you get after
>>>>> the failed sync.
>>>>>
>>>>> The resumable download feature does address this problem, I hope: each
>>>>> time you synchronize, though it's cut off, you do receive something
>>>>> and progress is made because the resumable download feature continues
>>>>> from where it left off on the next sync call. This will work as long
>>>>> as the network allows more traffic through on subsequent connections.
>>>>> Basically, the feature allows the download to be received over many
>>>>> shorter sync sessions.
>>>>>
>>>>> - Tim
>>>>>
>>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>>> news:4e8f77a8$1@forums-1-dub...
>>>>>> Hi Tim,
>>>>>>
>>>>>> Our application just gets a Synchronisation Failed message.
>>>>>>
>>>>>> The problem isn't whether or not the Ultralite is robust enough to
>>>>>> handle it. The problem is that if the O2 network cuts off the
>>>>>> transmission after a certain size, if we are ever in a situation
>>>>>> where the client application needs to rebuild the database, the
>>>>>> initial sync is too large for it to work over the air.
>>>>>>
>>>>>> Therefore having a database with the initial sync done with the
>>>>>> majority of reference data means that a new database can always be
>>>>>> created within the application by copying the database that has had
>>>>>> the initial sync performed.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Shao
>>>>>>
>>>>>>
>>>>>> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in
>>>>>> message news:4e8f4d70@forums-1-dub...
>>>>>>> Hi Shao,
>>>>>>>
>>>>>>> Do you know what error you get on the synchronize call in this case?
>>>>>>>
>>>>>>> UL's resumable download feature is designed to handle cases like
>>>>>>> this...
>>>>>>>
>>>>>>> - Tim
>>>>>>>
>>>>>>>
>>>>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>>>>> news:4e8ecb56@forums-1-dub...
>>>>>>>> Oh, one other thing everyone at iAnywhere may need to be aware
>>>>>>>> of.....
>>>>>>>>
>>>>>>>> We have found that users on the O2 network, when doing an initial
>>>>>>>> sync, if the sync traffic is greater than 3-5Mb (not really sure of
>>>>>>>> the exact amount), the sync will fail. We try using a T-Mobile or
>>>>>>>> Orange SIM and the sync will work fine.
>>>>>>>>
>>>>>>>> It seems that for one reason or another, O2 is stopping large
>>>>>>>> download syncs. This may be because its TCP traffic that its
>>>>>>>> trapping or something else.
>>>>>>>>
>>>>>>>> Anyway, whilst some customers are happy to cradle a device in
>>>>>>>> office to do the initial sync, others may not. And when moving to
>>>>>>>> other platforms where cradling a device may not be an option and
>>>>>>>> for security reasons, using a local WiFi may not be an option
>>>>>>>> either, I do think that iAnywhere exploring a clean way to do an
>>>>>>>> initial sync without issues of the second user logging on resulting
>>>>>>>> in the same data coming down a second time may be something
>>>>>>>> worthwhile.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Shao
>>>>>>>>
>>>>>>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>>>>>>> news:4e8db56a$1@forums-1-dub...
>>>>>>>>> Hi Reg,
>>>>>>>>>
>>>>>>>>> Thanks for the detailed response. I think I'm going to have to
>>>>>>>>> give this one some thought.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Shao
>>>>>>>>>
>>>>>>>>> "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in
>>>>>>>>> message news:4e8dae9e@forums-1-dub...
>>>>>>>>>> Shao, if the data that you are pre-populating into the ULDB is
>>>>>>>>>> from tables that are also synchronize using a timestamp based
>>>>>>>>>> approach, you'll have this problem regardless of how you
>>>>>>>>>> initially populate the ULDB.
>>>>>>>>>>
>>>>>>>>>> Here's one option:
>>>>>>>>>>
>>>>>>>>>> When you initially populate the database with data at time "t2"
>>>>>>>>>> (it's important to note that time "t2" is the time that you
>>>>>>>>>> pulled the data from the consolidate, and it's the time at the
>>>>>>>>>> consolidated database), I would suggest storing time "t2" in your
>>>>>>>>>> remote database, possibly in a table that doesn't synch. Now,
>>>>>>>>>> whenever you synchronize, you send up an authentication parameter
>>>>>>>>>> that will tell the MobiLink Server at what time the subset of
>>>>>>>>>> initial data was generated for this remote. You can now change
>>>>>>>>>> your synchronization scripts on tables that included initial data
>>>>>>>>>> to read :
>>>>>>>>>>
>>>>>>>>>> select pk,c1,c2
>>>>>>>>>> from t1
>>>>>>>>>> where last_mod >= max( {ml s.last_table_download}, {ml a.1} )
>>>>>>>>>>
>>>>>>>>>> So, for the initial synch, when {ml s.last_table_download} is
>>>>>>>>>> '1900-01-01 00:00:00.000', the authentication parameter will be
>>>>>>>>>> used, but in subsequent synchs, {ml s.last_table_download} will
>>>>>>>>>> be greater than {ml a.1}.
>>>>>>>>>>
>>>>>>>>>> This does mean that you're sending an authentication parameter
>>>>>>>>>> that's around 20 bytes in size for every synchronization, but it
>>>>>>>>>> will allow you to pre-populate your remote database with some of
>>>>>>>>>> the data, but not tie the database to a particular remote_id or
>>>>>>>>>> MobiLink User name before you send it out.
>>>>>>>>>>
>>>>>>>>>> If sending the authentication parameter after the initial
>>>>>>>>>> synchronization is an issue, you could define two script versions
>>>>>>>>>> in the ML Server, one that uses the authentication parameter, and
>>>>>>>>>> one that doesn't. When you app decides it wants to synch, it
>>>>>>>>>> checks to see whether time "t2" is stored in the database. If it
>>>>>>>>>> is, send the authentication parameter and use script version
>>>>>>>>>> "shao_withAP". Once there is a successful synch using this
>>>>>>>>>> script version, delete time "t2" from the database. Subsequent
>>>>>>>>>> synchronizations will detect that time "t2" doesn't exist in the
>>>>>>>>>> database, will not define an authentication parameter, and will
>>>>>>>>>> use script version "shao", which doesn't require an
>>>>>>>>>> authentication parameter.
>>>>>>>>>>
>>>>>>>>>> There are probably other solutions, but this is first one that
>>>>>>>>>> came to mind.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Reg Domaratzki - Sybase
>>>>>>>>>> Please reply only to the newsgroup
>>>>>>>>>>
>>>>>>>>>> Documentation : Exercise your WRITE @DocCommentXchange:
>>>>>>>>>> DCX.sybase.com
>>>>>>>>>> SQL Anywhere Patches and EBFs :
>>>>>>>>>> http://downloads.sybase.com/swd/base.do
>>>>>>>>>> -> Choose SQL Anywhere
>>>>>>>>>> -> Optionally set filter to "Display ALL platforms IN ALL
>>>>>>>>>> MONTHS"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


Jeff Albion [Sybase iAnywhere] Posted on 2011-10-13 18:14:02.0Z
From: "Jeff Albion [Sybase iAnywhere]" <firstname.lastname@sybase.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
Newsgroups: sybase.public.sqlanywhere.ultralite
Subject: Re: Initial sync with Ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub> <4e8ecb56@forums-1-dub> <4e8f4d70@forums-1-dub> <4e8f77a8$1@forums-1-dub>
In-Reply-To: <4e8f77a8$1@forums-1-dub>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e972a6a@forums-1-dub>
Date: 13 Oct 2011 11:14:02 -0700
X-Trace: forums-1-dub 1318529642 10.22.241.152 (13 Oct 2011 11:14:02 -0700)
X-Original-Trace: 13 Oct 2011 11:14:02 -0700, vip152.sybase.com
Lines: 29
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12632
Article PK: 1048427

Hi Shao,

On 07/10/2011 6:05 PM, Shao Chan wrote:
> The problem isn't whether or not the Ultralite is robust enough to handle
> it. The problem is that if the O2 network cuts off the transmission after a
> certain size, if we are ever in a situation where the client application
> needs to rebuild the database, the initial sync is too large for it to work
> over the air.

Which version of UltraLite / MobiLink are you seeing this behaviour
with? Which protocol type are you using?

As an FYI, in 12.0.1 (GA) there was a feature added to make HTTP-based
synchronizations more robust (e.g. 'background retry') for all MobiLink
clients (except UltraLiteJ).

Regards,

--
Jeff Albion, Sybase iAnywhere, an SAP Company

SQL Anywhere Developer Community :
http://www.sybase.com/developer/library/sql-anywhere-techcorner
SQL Anywhere Documentation : http://dcx.sybase.com/
Archived SQL Anywhere Documentation :
http://manuals.sybase.com/onlinebooks/group-sas/
SQL Anywhere Patches and EBFs :
http://downloads.sybase.com/swd/summary.do?baseprod=144&client=ianywhere&timeframe=0
Report a Bug/Open a Case : http://case-express.sybase.com/cx/


Shao Chan Posted on 2011-10-13 23:03:33.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8dae9e@forums-1-dub> <4e8db56a$1@forums-1-dub> <4e8ecb56@forums-1-dub> <4e8f4d70@forums-1-dub> <4e8f77a8$1@forums-1-dub> <4e972a6a@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 61
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e976e45$1@forums-1-dub>
Date: 13 Oct 2011 16:03:33 -0700
X-Trace: forums-1-dub 1318547013 10.22.241.152 (13 Oct 2011 16:03:33 -0700)
X-Original-Trace: 13 Oct 2011 16:03:33 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12634
Article PK: 1048430

Hi Jeff,

We're seeing it in 9.0.2. on TCP/IP.

We believe the problem is O2 stopping large TCP syncs on 'smartphone' data
tarriffs which are more restricted than normal data tarriffs for dongles
where they don't restrict use.

However, I am unsure as things change over time. In the past 'smartphone'
type tarriffs were bolted onto normal phone tarriffs and intended to do
simple mobile surfing of the internet and so you get a small allowance which
was monitored. Since the advent of the iPhone and now smartphones in
general were people are on YouTube etc, things might have changed.

Nevertheless, customers on O2 cannot on their mobile tarriffs perform a
large sync. This is usually the initial sync where all the data is sent to
the PDA.

This may well improve in 12.0.1. if the retry where it left off changes
things.

Thanks,

Shao

"Jeff Albion [Sybase iAnywhere]" <firstname.lastname@sybase.com> wrote in
message news:4e972a6a@forums-1-dub...
> Hi Shao,
>
> On 07/10/2011 6:05 PM, Shao Chan wrote:
>> The problem isn't whether or not the Ultralite is robust enough to handle
>> it. The problem is that if the O2 network cuts off the transmission
>> after a
>> certain size, if we are ever in a situation where the client application
>> needs to rebuild the database, the initial sync is too large for it to
>> work
>> over the air.
>
> Which version of UltraLite / MobiLink are you seeing this behaviour with?
> Which protocol type are you using?
>
> As an FYI, in 12.0.1 (GA) there was a feature added to make HTTP-based
> synchronizations more robust (e.g. 'background retry') for all MobiLink
> clients (except UltraLiteJ).
>
> Regards,
>
> --
> Jeff Albion, Sybase iAnywhere, an SAP Company
>
> SQL Anywhere Developer Community :
> http://www.sybase.com/developer/library/sql-anywhere-techcorner
> SQL Anywhere Documentation : http://dcx.sybase.com/
> Archived SQL Anywhere Documentation :
> http://manuals.sybase.com/onlinebooks/group-sas/
> SQL Anywhere Patches and EBFs :
> http://downloads.sybase.com/swd/summary.do?baseprod=144&client=ianywhere&timeframe=0
> Report a Bug/Open a Case : http://case-express.sybase.com/cx/


Tim McClements [Sybase] Posted on 2011-10-07 19:16:19.0Z
From: "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 164
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8f5003$1@forums-1-dub>
Date: 7 Oct 2011 12:16:19 -0700
X-Trace: forums-1-dub 1318014979 10.22.241.152 (7 Oct 2011 12:16:19 -0700)
X-Original-Trace: 7 Oct 2011 12:16:19 -0700, vip152.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12617
Article PK: 1048405

Hi Shao,

I might not understand your question, but as far as I know you shouldn't
have to do anything special at all for this to work. (Yes, this is a
different answer than Reg's post.)

It should just work because the UL database saves the last download
timestamps. Even when the remote ID is changed, the correct timestamps will
be sent to the server for subsequent syncs so you'll get only new data. (The
server might store some timestamp values, but it really uses the ones sent
from the remote. Is that the point of confusion I wonder?)

I will discuss this further and we'll get back to you with a more definite
answer - sorry for the confusion.

- Tim

"Shao Chan" <nospam@nospam.com> wrote in message
news:4e8d8b4f$1@forums-1-dub...
> Hi Tim,
>
> Thanks for that.
>
> Just one question. Synchronisation usually is timestamp based.
>
> If we do an initial sync and then remove the remoteid, we'd still want to
> ensure that when the user logs in with the real user that the data doesn't
> come down again.
>
> I.e.
> Time t1 - SQL Anywhere database loaded with all data.
> Time t2 - Ultralite syncs with R1
> Time t3 - Ultralite R1 user is removed but synched until time t2 is
> remembered.
> Time t4 - Ultralite syncs with R2 remembering to sync since time t2
>
> If I recall correctly, possibly this time of last sync is held on the SQL
> Anywhere database somewhere and only is reset if the user's udb is
> deleted. I believe that's how it works in 9.0.2. in our database.
>
> Will remembering not to sync before time t2 have to be hard coded into our
> application somewhere if we use this approach or is that already/easily
> taken care of?
>
> Cheers,
>
> Shao
>
>
> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
> news:4e8ca84d$1@forums-1-dub...
>> You could pre-populate using ulsync, ulinit (from a reference database),
>> or ulload (from an XML file). Note that ulinit and ulload have special
>> functionality such that the rows they insert will _not_ be uploaded on a
>> subsequent sync. (If you run your own insert statements you will have
>> this problem.)
>>
>> I agree that doing an initial sync is a natural way to do this, and
>> that's fine. All you have to do is execute "set option ml_remote_id="
>> after syncrhonizing to clear the remote ID. Here's a command which does
>> that:
>>
>> dbisql -ul -c dbf=t.udb "set option ml_remote_id="
>>
>> If desired you could also set the remote ID to something specific before
>> doing the initial sync, to avoid adding extra remote ID entries to the ML
>> system tables.
>>
>> dbisql -ul -c dbf=t.udb "set option ml_remote_id=initial_sync"
>> ulsync ...
>>
>> - Tim
>>
>> "Shao Chan" <nospam@nospam.com> wrote in message
>> news:4e8c0990@forums-1-dub...
>>> Hi Graham,
>>>
>>> Thanks for that.
>>>
>>> So, when you say to populate the template database, I assume you're
>>> meaning that I should export from the SQL Anywhere database and import
>>> into the Ultralite on the server using DML scripts? Is there a
>>> better/easier way of achieving this?
>>>
>>> I was thinking that a lot of business applications will have a situation
>>> where a lot of lookup data is required - in many situations where
>>> workmen lookup data on a table rather than browing a 5000 page manual
>>> for a code, etc. It would be great to have an easy way of getting this
>>> data pre-installed onto the database.
>>>
>>> In other situations, customers will setup their own cost data which may
>>> change annually. Ideally I'd rather initially send out a blank database
>>> with the application, but for some customers, once the SQL Anywhere
>>> database is all correctly setup with all the data to do an initial sync,
>>> find an easy way to remove any remote id etc, and compile it into the
>>> application so that it goes out with a database with the correct lookup
>>> data.
>>>
>>> Any changes in the Ultralite products (even a ulsync command to say
>>> ulsync -delete remoteid or something) to achieve the desired effect?
>>>
>>> Thanks,
>>>
>>> Shao
>>>
>>>
>>> "Graham Hurst [Sybase iAnywhere]" <spam_guard_hurst@ianywhere.com> wrote
>>> in message news:4e8b7f84$1@forums-1-dub...
>>>> It would be simplest to use something other than synchronization to
>>>> pre-populate the template database.
>>>>
>>>> The problem is that every remote database has to have a unique remote
>>>> ID, and synchronization assigns a remote ID (see
>>>> http://dcx.sybase.com/index.html#1201/en/mlclient/mc-users-s-6422554.html*d5e595).
>>>> If you copy a synchronized database, you have to clear the remote ID
>>>> and probably clear anything associated with it from the consolidated
>>>> database.
>>>>
>>>> It's much safer to copy a template database that has never been
>>>> synchronized than to have to clean one that has been synchronized.
>>>>
>>>> Cheers,
>>>>
>>>> Graham
>>>>
>>>> On 2011-09-30 3:07 PM, Shao Chan wrote:
>>>>> Hi all,
>>>>>
>>>>> If writing an application using Android Ultralite and keeping the UDB
>>>>> as
>>>>> part of the project build, ideally I'd want to be able to do an
>>>>> initial sync
>>>>> to get the majority of static lookup table data (e.g. I have one
>>>>> lookup
>>>>> table with 60K rows) but not commit a user to the database.
>>>>>
>>>>> This database would then be shipped with the application and then when
>>>>> the
>>>>> user logs on they don't need to sync all the referential data.
>>>>>
>>>>> Obviously, as this database will be part of the application and given
>>>>> to
>>>>> every user so the initial sync has to be with a special user of some
>>>>> kind.
>>>>>
>>>>> Is this possible to achieve this or is this kind of functionality in
>>>>> the
>>>>> pipeline?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Shao
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>


Shao Chan Posted on 2011-10-07 22:02:29.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8f5003$1@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 186
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e8f76f5$1@forums-1-dub>
Date: 7 Oct 2011 15:02:29 -0700
X-Trace: forums-1-dub 1318024949 10.22.241.152 (7 Oct 2011 15:02:29 -0700)
X-Original-Trace: 7 Oct 2011 15:02:29 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12619
Article PK: 1048408

Hi Tim,

Thanks for the reply.

That sounds promising.

If the remote last sync timestamp does not change with the change of the
remoteId then I do think that it will work.

If you could confirm that this is correct and that there are no adverse
effects in doing this, it would be greatly appreciated.

Thanks,

Shao

"Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
news:4e8f5003$1@forums-1-dub...
> Hi Shao,
>
> I might not understand your question, but as far as I know you shouldn't
> have to do anything special at all for this to work. (Yes, this is a
> different answer than Reg's post.)
>
> It should just work because the UL database saves the last download
> timestamps. Even when the remote ID is changed, the correct timestamps
> will be sent to the server for subsequent syncs so you'll get only new
> data. (The server might store some timestamp values, but it really uses
> the ones sent from the remote. Is that the point of confusion I wonder?)
>
> I will discuss this further and we'll get back to you with a more definite
> answer - sorry for the confusion.
>
> - Tim
>
>
> "Shao Chan" <nospam@nospam.com> wrote in message
> news:4e8d8b4f$1@forums-1-dub...
>> Hi Tim,
>>
>> Thanks for that.
>>
>> Just one question. Synchronisation usually is timestamp based.
>>
>> If we do an initial sync and then remove the remoteid, we'd still want to
>> ensure that when the user logs in with the real user that the data
>> doesn't come down again.
>>
>> I.e.
>> Time t1 - SQL Anywhere database loaded with all data.
>> Time t2 - Ultralite syncs with R1
>> Time t3 - Ultralite R1 user is removed but synched until time t2 is
>> remembered.
>> Time t4 - Ultralite syncs with R2 remembering to sync since time t2
>>
>> If I recall correctly, possibly this time of last sync is held on the SQL
>> Anywhere database somewhere and only is reset if the user's udb is
>> deleted. I believe that's how it works in 9.0.2. in our database.
>>
>> Will remembering not to sync before time t2 have to be hard coded into
>> our application somewhere if we use this approach or is that
>> already/easily taken care of?
>>
>> Cheers,
>>
>> Shao
>>
>>
>> "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com> wrote in message
>> news:4e8ca84d$1@forums-1-dub...
>>> You could pre-populate using ulsync, ulinit (from a reference database),
>>> or ulload (from an XML file). Note that ulinit and ulload have special
>>> functionality such that the rows they insert will _not_ be uploaded on a
>>> subsequent sync. (If you run your own insert statements you will have
>>> this problem.)
>>>
>>> I agree that doing an initial sync is a natural way to do this, and
>>> that's fine. All you have to do is execute "set option ml_remote_id="
>>> after syncrhonizing to clear the remote ID. Here's a command which does
>>> that:
>>>
>>> dbisql -ul -c dbf=t.udb "set option ml_remote_id="
>>>
>>> If desired you could also set the remote ID to something specific before
>>> doing the initial sync, to avoid adding extra remote ID entries to the
>>> ML system tables.
>>>
>>> dbisql -ul -c dbf=t.udb "set option ml_remote_id=initial_sync"
>>> ulsync ...
>>>
>>> - Tim
>>>
>>> "Shao Chan" <nospam@nospam.com> wrote in message
>>> news:4e8c0990@forums-1-dub...
>>>> Hi Graham,
>>>>
>>>> Thanks for that.
>>>>
>>>> So, when you say to populate the template database, I assume you're
>>>> meaning that I should export from the SQL Anywhere database and import
>>>> into the Ultralite on the server using DML scripts? Is there a
>>>> better/easier way of achieving this?
>>>>
>>>> I was thinking that a lot of business applications will have a
>>>> situation where a lot of lookup data is required - in many situations
>>>> where workmen lookup data on a table rather than browing a 5000 page
>>>> manual for a code, etc. It would be great to have an easy way of
>>>> getting this data pre-installed onto the database.
>>>>
>>>> In other situations, customers will setup their own cost data which may
>>>> change annually. Ideally I'd rather initially send out a blank
>>>> database with the application, but for some customers, once the SQL
>>>> Anywhere database is all correctly setup with all the data to do an
>>>> initial sync, find an easy way to remove any remote id etc, and compile
>>>> it into the application so that it goes out with a database with the
>>>> correct lookup data.
>>>>
>>>> Any changes in the Ultralite products (even a ulsync command to say
>>>> ulsync -delete remoteid or something) to achieve the desired effect?
>>>>
>>>> Thanks,
>>>>
>>>> Shao
>>>>
>>>>
>>>> "Graham Hurst [Sybase iAnywhere]" <spam_guard_hurst@ianywhere.com>
>>>> wrote in message news:4e8b7f84$1@forums-1-dub...
>>>>> It would be simplest to use something other than synchronization to
>>>>> pre-populate the template database.
>>>>>
>>>>> The problem is that every remote database has to have a unique remote
>>>>> ID, and synchronization assigns a remote ID (see
>>>>> http://dcx.sybase.com/index.html#1201/en/mlclient/mc-users-s-6422554.html*d5e595).
>>>>> If you copy a synchronized database, you have to clear the remote ID
>>>>> and probably clear anything associated with it from the consolidated
>>>>> database.
>>>>>
>>>>> It's much safer to copy a template database that has never been
>>>>> synchronized than to have to clean one that has been synchronized.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Graham
>>>>>
>>>>> On 2011-09-30 3:07 PM, Shao Chan wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> If writing an application using Android Ultralite and keeping the UDB
>>>>>> as
>>>>>> part of the project build, ideally I'd want to be able to do an
>>>>>> initial sync
>>>>>> to get the majority of static lookup table data (e.g. I have one
>>>>>> lookup
>>>>>> table with 60K rows) but not commit a user to the database.
>>>>>>
>>>>>> This database would then be shipped with the application and then
>>>>>> when the
>>>>>> user logs on they don't need to sync all the referential data.
>>>>>>
>>>>>> Obviously, as this database will be part of the application and given
>>>>>> to
>>>>>> every user so the initial sync has to be with a special user of some
>>>>>> kind.
>>>>>>
>>>>>> Is this possible to achieve this or is this kind of functionality in
>>>>>> the
>>>>>> pipeline?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Shao
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


Reg Domaratzki [Sybase] Posted on 2011-10-11 19:18:20.0Z
From: "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com>
Reply-To: firstname.lastname@sybase.com
Organization: Sybase, an SAP Company
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.23) Gecko/20110920 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
Newsgroups: sybase.public.sqlanywhere.ultralite
Subject: Re: Initial sync with Ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8f5003$1@forums-1-dub>
In-Reply-To: <4e8f5003$1@forums-1-dub>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e94967c$1@forums-1-dub>
Date: 11 Oct 2011 12:18:20 -0700
X-Trace: forums-1-dub 1318360700 10.22.241.152 (11 Oct 2011 12:18:20 -0700)
X-Original-Trace: 11 Oct 2011 12:18:20 -0700, vip152.sybase.com
Lines: 60
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12622
Article PK: 1048413


On 10/7/2011 3:16 PM, Tim McClements [Sybase] wrote:
> Hi Shao,
>
> I might not understand your question, but as far as I know you shouldn't
> have to do anything special at all for this to work. (Yes, this is a
> different answer than Reg's post.)
>
> It should just work because the UL database saves the last download
> timestamps. Even when the remote ID is changed, the correct timestamps will
> be sent to the server for subsequent syncs so you'll get only new data. (The
> server might store some timestamp values, but it really uses the ones sent
> from the remote. Is that the point of confusion I wonder?)
>
> I will discuss this further and we'll get back to you with a more definite
> answer - sorry for the confusion.
>
> - Tim
>
>

Tim and I figured today out why we didn't agree with each other on this
question, and it came from the fact that Tim is an UltraLite expert, and
I'm an expert on MobiLink and dbmlsync. UltraLite and SQL Anywhere
remotes differ slightly on how the last download timestamp is maintained
when you synchronize with different MobiLink users. My points were all
valid for UltraLite if you only had a single publication in the
UltraLite remote database, but there is a much easier solution for
UltraLite that involves multiple publications that I'll outline below.

Here's the short answer :

1) Create a publication (I'll call it pub_all) that includes all the
tables that will be involved in your initial synchronization. Since you
don't want to tie the database to a particular user at this point, none
of the tables in this publication will have scripts in the MobiLink
Server that partition based on the remote ID or MobiLink user name used
in the initial synchronization.

2) Create a 2nd publication (I'll call it pub_user) that includes the
rest of the tables in your UltraLite remote.

3) Do your initial synchronization with an ML User called something like
"initial_synch", and only synchronize the pub_all publication. Deploy
the UL database.

4) Once deployed, set the Remote ID of the database to the value you
want, and then begin synchronizing with the MobiLink user that you want
for this remote database. When you synchronize, synchronize both the
pub_all and pub_user publications at the same time.

I hope this clears things up.

--
Reg Domaratzki - Sybase
Please reply only to the newsgroup

Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
SQL Anywhere Patches and EBFs : http://downloads.sybase.com/swd/base.do
-> Choose SQL Anywhere
-> Optionally set filter to "Display ALL platforms IN ALL MONTHS"


Shao Chan Posted on 2011-10-12 06:50:36.0Z
Reply-To: "Shao Chan" <nospam@nospam.com>
From: "Shao Chan" <nospam@nospam.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8f5003$1@forums-1-dub> <4e94967c$1@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 90
Organization: Civica
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e9538bc@forums-1-dub>
Date: 11 Oct 2011 23:50:36 -0700
X-Trace: forums-1-dub 1318402236 10.22.241.152 (11 Oct 2011 23:50:36 -0700)
X-Original-Trace: 11 Oct 2011 23:50:36 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12624
Article PK: 1048386

Hi Reg,

Thanks for that. I appreciate the time you and Tim took to discuss this
issue.

We'll be looking at implementing this. At the moment, we're just checking
the differences between 9.0.2. and 12.0.1. sync user / remote id changes
where in the past if a user logs onto one Ultralite database and syncs and
then onto a second, it will supercede the first so that it will no longer
sync. But now, they will both sync concurrently as uniqueness is not driven
by the sync user but by the remoteId I think. So we need to know how that
will affect our application, whether we need to change things back to how
they use to work possibly by manually changing the remoteId to a value that
correlates to the syncuser and then look at this afterwards as it is
affected by changes to the remoteId.

Thanks for yours and Tims help.

Cheers,

Shao

"Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in message
news:4e94967c$1@forums-1-dub...
> On 10/7/2011 3:16 PM, Tim McClements [Sybase] wrote:
>> Hi Shao,
>>
>> I might not understand your question, but as far as I know you shouldn't
>> have to do anything special at all for this to work. (Yes, this is a
>> different answer than Reg's post.)
>>
>> It should just work because the UL database saves the last download
>> timestamps. Even when the remote ID is changed, the correct timestamps
>> will
>> be sent to the server for subsequent syncs so you'll get only new data.
>> (The
>> server might store some timestamp values, but it really uses the ones
>> sent
>> from the remote. Is that the point of confusion I wonder?)
>>
>> I will discuss this further and we'll get back to you with a more
>> definite
>> answer - sorry for the confusion.
>>
>> - Tim
>>
>>
>
> Tim and I figured today out why we didn't agree with each other on this
> question, and it came from the fact that Tim is an UltraLite expert, and
> I'm an expert on MobiLink and dbmlsync. UltraLite and SQL Anywhere
> remotes differ slightly on how the last download timestamp is maintained
> when you synchronize with different MobiLink users. My points were all
> valid for UltraLite if you only had a single publication in the UltraLite
> remote database, but there is a much easier solution for UltraLite that
> involves multiple publications that I'll outline below.
>
> Here's the short answer :
>
> 1) Create a publication (I'll call it pub_all) that includes all the
> tables that will be involved in your initial synchronization. Since you
> don't want to tie the database to a particular user at this point, none of
> the tables in this publication will have scripts in the MobiLink Server
> that partition based on the remote ID or MobiLink user name used in the
> initial synchronization.
>
> 2) Create a 2nd publication (I'll call it pub_user) that includes the rest
> of the tables in your UltraLite remote.
>
> 3) Do your initial synchronization with an ML User called something like
> "initial_synch", and only synchronize the pub_all publication. Deploy the
> UL database.
>
> 4) Once deployed, set the Remote ID of the database to the value you want,
> and then begin synchronizing with the MobiLink user that you want for this
> remote database. When you synchronize, synchronize both the pub_all and
> pub_user publications at the same time.
>
> I hope this clears things up.
>
> --
> Reg Domaratzki - Sybase
> Please reply only to the newsgroup
>
> Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
> SQL Anywhere Patches and EBFs : http://downloads.sybase.com/swd/base.do
> -> Choose SQL Anywhere
> -> Optionally set filter to "Display ALL platforms IN ALL MONTHS"


Tim McClements [Sybase] Posted on 2011-10-12 19:41:08.0Z
From: "Tim McClements [Sybase]" <mcclemenXnospam@sybase.com>
Newsgroups: sybase.public.sqlanywhere.ultralite
References: <4e861366@forums-1-dub> <4e8b7f84$1@forums-1-dub> <4e8c0990@forums-1-dub> <4e8ca84d$1@forums-1-dub> <4e8d8b4f$1@forums-1-dub> <4e8f5003$1@forums-1-dub> <4e94967c$1@forums-1-dub> <4e9538bc@forums-1-dub>
Subject: Re: Initial sync with Ultralite
Lines: 112
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4e95ed54$1@forums-1-dub>
Date: 12 Oct 2011 12:41:08 -0700
X-Trace: forums-1-dub 1318448468 10.22.241.152 (12 Oct 2011 12:41:08 -0700)
X-Original-Trace: 12 Oct 2011 12:41:08 -0700, vip152.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.sqlanywhere.ultralite:12626
Article PK: 1048389

Hi Shao,

The remote ID was added because ML relies on each different remote database
having a different identifier. Previously, the user name was used for this,
but the user name is also used for authentication and data partioning and
really isn't a good value to rely on for uniqueness!

The remote ID, when unset, is generated automatically by UL (as a UUID) at
sync time. We let you set it if you want to bear the responsibility of
ensuring uniqueness and want to have a more meaningful identifier. But
really, the only time you _have_ to think about it is when copying/deploying
a database: you must clear it in that case.

- Tim

(P.S. have you considered trying sqlanywhere-forum.sybase.com to post your
questions?)

"Shao Chan" <nospam@nospam.com> wrote in message
news:4e9538bc@forums-1-dub...
> Hi Reg,
>
> Thanks for that. I appreciate the time you and Tim took to discuss this
> issue.
>
> We'll be looking at implementing this. At the moment, we're just checking
> the differences between 9.0.2. and 12.0.1. sync user / remote id changes
> where in the past if a user logs onto one Ultralite database and syncs and
> then onto a second, it will supercede the first so that it will no longer
> sync. But now, they will both sync concurrently as uniqueness is not
> driven by the sync user but by the remoteId I think. So we need to know
> how that will affect our application, whether we need to change things
> back to how they use to work possibly by manually changing the remoteId to
> a value that correlates to the syncuser and then look at this afterwards
> as it is affected by changes to the remoteId.
>
> Thanks for yours and Tims help.
>
> Cheers,
>
> Shao
>
> "Reg Domaratzki [Sybase]" <firstname.lastname@sybase.com> wrote in message
> news:4e94967c$1@forums-1-dub...
>> On 10/7/2011 3:16 PM, Tim McClements [Sybase] wrote:
>>> Hi Shao,
>>>
>>> I might not understand your question, but as far as I know you shouldn't
>>> have to do anything special at all for this to work. (Yes, this is a
>>> different answer than Reg's post.)
>>>
>>> It should just work because the UL database saves the last download
>>> timestamps. Even when the remote ID is changed, the correct timestamps
>>> will
>>> be sent to the server for subsequent syncs so you'll get only new data.
>>> (The
>>> server might store some timestamp values, but it really uses the ones
>>> sent
>>> from the remote. Is that the point of confusion I wonder?)
>>>
>>> I will discuss this further and we'll get back to you with a more
>>> definite
>>> answer - sorry for the confusion.
>>>
>>> - Tim
>>>
>>>
>>
>> Tim and I figured today out why we didn't agree with each other on this
>> question, and it came from the fact that Tim is an UltraLite expert, and
>> I'm an expert on MobiLink and dbmlsync. UltraLite and SQL Anywhere
>> remotes differ slightly on how the last download timestamp is maintained
>> when you synchronize with different MobiLink users. My points were all
>> valid for UltraLite if you only had a single publication in the UltraLite
>> remote database, but there is a much easier solution for UltraLite that
>> involves multiple publications that I'll outline below.
>>
>> Here's the short answer :
>>
>> 1) Create a publication (I'll call it pub_all) that includes all the
>> tables that will be involved in your initial synchronization. Since you
>> don't want to tie the database to a particular user at this point, none
>> of the tables in this publication will have scripts in the MobiLink
>> Server that partition based on the remote ID or MobiLink user name used
>> in the initial synchronization.
>>
>> 2) Create a 2nd publication (I'll call it pub_user) that includes the
>> rest of the tables in your UltraLite remote.
>>
>> 3) Do your initial synchronization with an ML User called something like
>> "initial_synch", and only synchronize the pub_all publication. Deploy
>> the UL database.
>>
>> 4) Once deployed, set the Remote ID of the database to the value you
>> want, and then begin synchronizing with the MobiLink user that you want
>> for this remote database. When you synchronize, synchronize both the
>> pub_all and pub_user publications at the same time.
>>
>> I hope this clears things up.
>>
>> --
>> Reg Domaratzki - Sybase
>> Please reply only to the newsgroup
>>
>> Documentation : Exercise your WRITE @DocCommentXchange: DCX.sybase.com
>> SQL Anywhere Patches and EBFs : http://downloads.sybase.com/swd/base.do
>> -> Choose SQL Anywhere
>> -> Optionally set filter to "Display ALL platforms IN ALL MONTHS"
>
>