SQL Anywhere ultralite - ulinit documentation

Author

ulinit documentation

rr12

2005-10-27, 7:41 am

The docs at...

UltraLite Database User's Guide
UltraLite Utilities Reference
The ulinit utility

....state that the "function" of ulinit is ...

"The ulinit utility lets you create a .usm file for use with any UltraLite
component. The utility connects to an Adaptive Server Anywhere database.
Consequently, SQL Anywhere Studio (version 8.0.2 or later) is required in
order to use it."

....however it does more than that.

It also adds the synchronization scripts to the consolidated database. This
is significant in that it will overwrite your customized scripts with
generic ones - important to know before you run ulinit.

I think the docs should indicate all of the actions taken by the utility. I
would also suggest a new parameter be added to ulinit which allows you to
generate the usm file without making any changes to the consolidated; since
most everyone will need to customize the synchronization scripts anyway.
I'd really rather have no scripts than the wrong scripts.

Is that resonable?

rr12

Greg Fenton

2005-10-27, 7:41 am

rr12 wrote:
>
> ...however it does more than that.
>
> It also adds the synchronization scripts to the consolidated database. This
> is significant in that it will overwrite your customized scripts with
> generic ones - important to know before you run ulinit.
>

True, and I will post a docs enhancement request. However realize that
it generates the same ScriptVersion scripts each time. We *strongly*
recommend that developers make their own ScriptVersion (e.g. 'v1.0' or
'myAppScript' or whatever) rather than rely on the default version
(which I believe is 'ul_default'??). You might start your ScriptVersion
by copying the default ones created by ulinit. And you can specify the
version under which you want scripts generated using the "-m" option.

Also realize that our team recommends the creation of a *reference*
database rather than running ulinit (or ulgen) against your consolidated
database.

> I think the docs should indicate all of the actions taken by the utility. I
> would also suggest a new parameter be added to ulinit which allows you to
> generate the usm file without making any changes to the consolidated; since
> most everyone will need to customize the synchronization scripts anyway.
> I'd really rather have no scripts than the wrong scripts.

Script generation and modification is about to take some huge steps
forward with new tools coming in the Jasper release.

greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/

rr12

2005-10-27, 7:41 am

Ok. So I'll change my 'version' to something useful like... app version
maybe? or is a separate version not connected to the app version better?

I'll also add -m delete_this to my ulinit command line.

So now this reference database thing...if my consolidated is not live and I
have copies of it; why do I need a reference? Seems like the docs are
recommending using sybase central to create a new database entirely...isn't
that too much work to go in and re-create all the tables, columns, keys,
etc? Seems highly inefficient. Surely that's not the best way? Why not
just use a my consolidated, create publications, then call ulinit?

Will the ul.net in jasper work with cf 2.0? (Sorry multiple topics)

rr12

"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:434c16da$1@foru
ms-1-dub...
> rr12 wrote:
>
> True, and I will post a docs enhancement request. However realize that it
> generates the same ScriptVersion scripts each time. We *strongly*
> recommend that developers make their own ScriptVersion (e.g. 'v1.0' or
> 'myAppScript' or whatever) rather than rely on the default version (which
> I believe is 'ul_default'??). You might start your ScriptVersion by
> copying the default ones created by ulinit. And you can specify the
> version under which you want scripts generated using the "-m" option.
>
> Also realize that our team recommends the creation of a *reference*
> database rather than running ulinit (or ulgen) against your consolidated
> database.
>
>
> Script generation and modification is about to take some huge steps
> forward with new tools coming in the Jasper release.
>
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/

Greg Fenton

2005-10-27, 7:41 am

rr12 wrote:
> Ok. So I'll change my 'version' to something useful like... app version
> maybe? or is a separate version not connected to the app version better?

App version is likely a good candidate, but to be technically accurate,
the ScriptVersion represents an "API" so any client that has the same
publication schema could use the same ScriptVersion. In reality, most
people use a different ScriptVersion for each application version.

> I'll also add -m delete_this to my ulinit command line.

You don't need to do this if you aren't relying on the default script
version.

> So now this reference database thing...if my consolidated is not live and I
> have copies of it;

Then your "offline consolidated" is, in effect, your reference. That's
just fine. For the static APIs (i.e. ulgen), you wouldn't want to use
the consolidated as it likely has too much data and so the static plan
analysis would not be accurate (a reference database should contain a
representative sample of data as expected in your typical UL remote).

>
> Will the ul.net in jasper work with cf 2.0? (Sorry multiple topics)
>

Separate questions should be posted in a separate thread, or else you
might not get an answer at all. I'm not sure what the plan is with
UL.NET and CF 2.0.

greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/

rr12

2005-10-27, 7:41 am

Thank you very much. Am I safe in assuming that the amount of data in my
reference database is not relevant when using ul.net?

"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:434d2f97$1@foru
ms-1-dub...
> rr12 wrote:
>
> App version is likely a good candidate, but to be technically accurate,
> the ScriptVersion represents an "API" so any client that has the same
> publication schema could use the same ScriptVersion. In reality, most
> people use a different ScriptVersion for each application version.
>
>
> You don't need to do this if you aren't relying on the default script
> version.
>
>
>
> Then your "offline consolidated" is, in effect, your reference. That's
> just fine. For the static APIs (i.e. ulgen), you wouldn't want to use the
> consolidated as it likely has too much data and so the static plan
> analysis would not be accurate (a reference database should contain a
> representative sample of data as expected in your typical UL remote).
>
>
> Separate questions should be posted in a separate thread, or else you
> might not get an answer at all. I'm not sure what the plan is with UL.NET
> and CF 2.0.
>
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/

Greg Fenton

2005-10-27, 7:41 am

rr12 wrote:
> Thank you very much. Am I safe in assuming that the amount of data in my
> reference database is not relevant when using ul.net?
>

Yes.

greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/

Sponsored Links