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.

Global AutoIncrement

4 posts in General Discussion Last posting was on 2008-07-17 13:43:15.0Z
Loya Posted on 2008-07-16 15:06:06.0Z
Reply-To: "Loya" <lkelso@isprit.com>
From: "Loya" <lkelso@isprit.com>
Newsgroups: ianywhere.public.general
Subject: Global AutoIncrement
Lines: 25
Organization: Isprit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <487e0e5e$1@forums-1-dub>
Date: 16 Jul 2008 08:06:06 -0700
X-Trace: forums-1-dub 1216220766 10.22.241.152 (16 Jul 2008 08:06:06 -0700)
X-Original-Trace: 16 Jul 2008 08:06:06 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:6973
Article PK: 5198

We are using iAnywhere verion 9.0.2 with EBF 3044

Many tables use the global autoincrement to generate their primary key.

The partition size on all those tables is set to 10,000

So every couple of weeks we have to go out and add one to the global db id.

Here are my questions:

What would be my best startegy to fix this
1. Up the partition size by adding a couple of zeros?
a.) If I do that, do I just need to do the tables that get a lot of
data, or all tables?
b.) What is the max number of zeros I can add for a data type of
integer.

2. Could I change the field type on an existing database to a GUID?
If I did that, could I just do some tables, or is that not a
recommended method.

Thanks
Loya


"Nick Elson" < Posted on 2008-07-16 16:49:09.0Z
From: "Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@>
Newsgroups: ianywhere.public.general
References: <487e0e5e$1@forums-1-dub>
Subject: Re: Global AutoIncrement
Lines: 67
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <487e2685$1@forums-1-dub>
Date: 16 Jul 2008 09:49:09 -0700
X-Trace: forums-1-dub 1216226949 10.22.241.152 (16 Jul 2008 09:49:09 -0700)
X-Original-Trace: 16 Jul 2008 09:49:09 -0700, vip152.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:6974
Article PK: 5199

You can always use a GUID if that is your preference.
GUIDs are great for automation, not so great in the
human readable department. If these keys are to
have some meaning to people, then using an
unsigned BIG INT or a huge NUMERIC/DECIMAL(n,0)
can be friendlier and less error prone if people must
key in search values etc; and my preference usually.

But sticking with the global autoincrement, adjusting
partition size to suit the degree of churning on a per
table basis is a correct approach. The biggest trick
here is to find your best and safest balance across
all anticipated uses.

For what it is worth partition sizes do not need to
be some power of ten (ie decimal). I am somewhat
fonder of powers of 2 for integer types, but that
is a little less human friendly. In the same vein I
am fond of powers of 10 for BCD type (ie decimal /
numeric).

As to datatypes here are your options and precisions:

Unsigned BIGINT:
0 to 264 - 1, or 0 to 18446744073709551615
Maximal Usable Partition = 10E19 (19 zeros)

Unsigned INTEGER:
0 to 232 - 1, or 0 to 4294967295
Maximal Usable Partition = 10E9 (9 zeros)

DECIMAL/NUMERIC:
precision An integer expression between 1 and 127
Maximal Usable Partition = precision (up to 126 zeros)

Smaller integer types are going to be less.

"Loya" <lkelso@isprit.com> wrote in message news:487e0e5e$1@forums-1-dub...
> We are using iAnywhere verion 9.0.2 with EBF 3044
>
> Many tables use the global autoincrement to generate their primary key.
>
> The partition size on all those tables is set to 10,000
>
> So every couple of weeks we have to go out and add one to the global db
> id.
>
> Here are my questions:
>
> What would be my best startegy to fix this
> 1. Up the partition size by adding a couple of zeros?
> a.) If I do that, do I just need to do the tables that get a lot of
> data, or all tables?
> b.) What is the max number of zeros I can add for a data type of
> integer.
>
> 2. Could I change the field type on an existing database to a GUID?
> If I did that, could I just do some tables, or is that not a
> recommended method.
>
> Thanks
> Loya
>


Loya Posted on 2008-07-17 13:33:48.0Z
Reply-To: "Loya" <lkelso@isprit.com>
From: "Loya" <lkelso@isprit.com>
Newsgroups: ianywhere.public.general
References: <487e0e5e$1@forums-1-dub> <487e2685$1@forums-1-dub>
Subject: Re: Global AutoIncrement
Lines: 75
Organization: Isprit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <487f4a3c$1@forums-1-dub>
Date: 17 Jul 2008 06:33:48 -0700
X-Trace: forums-1-dub 1216301628 10.22.241.152 (17 Jul 2008 06:33:48 -0700)
X-Original-Trace: 17 Jul 2008 06:33:48 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:6975
Article PK: 5200

Nick,
Thanks for all the great information!
Loya

"Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@> wrote in message
news:487e2685$1@forums-1-dub...
> You can always use a GUID if that is your preference.
> GUIDs are great for automation, not so great in the
> human readable department. If these keys are to
> have some meaning to people, then using an
> unsigned BIG INT or a huge NUMERIC/DECIMAL(n,0)
> can be friendlier and less error prone if people must
> key in search values etc; and my preference usually.
>
> But sticking with the global autoincrement, adjusting
> partition size to suit the degree of churning on a per
> table basis is a correct approach. The biggest trick
> here is to find your best and safest balance across
> all anticipated uses.
>
> For what it is worth partition sizes do not need to
> be some power of ten (ie decimal). I am somewhat
> fonder of powers of 2 for integer types, but that
> is a little less human friendly. In the same vein I
> am fond of powers of 10 for BCD type (ie decimal /
> numeric).
>
> As to datatypes here are your options and precisions:
>
> Unsigned BIGINT:
> 0 to 264 - 1, or 0 to 18446744073709551615
> Maximal Usable Partition = 10E19 (19 zeros)
>
> Unsigned INTEGER:
> 0 to 232 - 1, or 0 to 4294967295
> Maximal Usable Partition = 10E9 (9 zeros)
>
> DECIMAL/NUMERIC:
> precision An integer expression between 1 and 127
> Maximal Usable Partition = precision (up to 126 zeros)
>
> Smaller integer types are going to be less.
>
>
>
> "Loya" <lkelso@isprit.com> wrote in message
> news:487e0e5e$1@forums-1-dub...
>> We are using iAnywhere verion 9.0.2 with EBF 3044
>>
>> Many tables use the global autoincrement to generate their primary key.
>>
>> The partition size on all those tables is set to 10,000
>>
>> So every couple of weeks we have to go out and add one to the global db
>> id.
>>
>> Here are my questions:
>>
>> What would be my best startegy to fix this
>> 1. Up the partition size by adding a couple of zeros?
>> a.) If I do that, do I just need to do the tables that get a lot of
>> data, or all tables?
>> b.) What is the max number of zeros I can add for a data type of
>> integer.
>>
>> 2. Could I change the field type on an existing database to a GUID?
>> If I did that, could I just do some tables, or is that not a
>> recommended method.
>>
>> Thanks
>> Loya
>>
>
>


"Nick Elson" < Posted on 2008-07-17 13:43:15.0Z
From: "Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@>
Newsgroups: ianywhere.public.general
References: <487e0e5e$1@forums-1-dub> <487e2685$1@forums-1-dub> <487f4a3c$1@forums-1-dub>
Subject: Re: Global AutoIncrement
Lines: 89
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <487f4c73$1@forums-1-dub>
Date: 17 Jul 2008 06:43:15 -0700
X-Trace: forums-1-dub 1216302195 10.22.241.152 (17 Jul 2008 06:43:15 -0700)
X-Original-Trace: 17 Jul 2008 06:43:15 -0700, vip152.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:6976
Article PK: 5201

No problem ...

For what it is worth my Maximal Usable Partion
sizes are missing a decimal point. In stead of,
say,
10E19 (19 zeros)
that should have been
1.0E19 (19 zeros)

"Loya" <lkelso@isprit.com> wrote in message news:487f4a3c$1@forums-1-dub...
> Nick,
> Thanks for all the great information!
> Loya
> "Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@> wrote in message
> news:487e2685$1@forums-1-dub...
>> You can always use a GUID if that is your preference.
>> GUIDs are great for automation, not so great in the
>> human readable department. If these keys are to
>> have some meaning to people, then using an
>> unsigned BIG INT or a huge NUMERIC/DECIMAL(n,0)
>> can be friendlier and less error prone if people must
>> key in search values etc; and my preference usually.
>>
>> But sticking with the global autoincrement, adjusting
>> partition size to suit the degree of churning on a per
>> table basis is a correct approach. The biggest trick
>> here is to find your best and safest balance across
>> all anticipated uses.
>>
>> For what it is worth partition sizes do not need to
>> be some power of ten (ie decimal). I am somewhat
>> fonder of powers of 2 for integer types, but that
>> is a little less human friendly. In the same vein I
>> am fond of powers of 10 for BCD type (ie decimal /
>> numeric).
>>
>> As to datatypes here are your options and precisions:
>>
>> Unsigned BIGINT:
>> 0 to 264 - 1, or 0 to 18446744073709551615
>> Maximal Usable Partition = 10E19 (19 zeros)
>>
>> Unsigned INTEGER:
>> 0 to 232 - 1, or 0 to 4294967295
>> Maximal Usable Partition = 10E9 (9 zeros)
>>
>> DECIMAL/NUMERIC:
>> precision An integer expression between 1 and 127
>> Maximal Usable Partition = precision (up to 126 zeros)
>>
>> Smaller integer types are going to be less.
>>
>>
>>
>> "Loya" <lkelso@isprit.com> wrote in message
>> news:487e0e5e$1@forums-1-dub...
>>> We are using iAnywhere verion 9.0.2 with EBF 3044
>>>
>>> Many tables use the global autoincrement to generate their primary key.
>>>
>>> The partition size on all those tables is set to 10,000
>>>
>>> So every couple of weeks we have to go out and add one to the global db
>>> id.
>>>
>>> Here are my questions:
>>>
>>> What would be my best startegy to fix this
>>> 1. Up the partition size by adding a couple of zeros?
>>> a.) If I do that, do I just need to do the tables that get a lot of
>>> data, or all tables?
>>> b.) What is the max number of zeros I can add for a data type of
>>> integer.
>>>
>>> 2. Could I change the field type on an existing database to a GUID?
>>> If I did that, could I just do some tables, or is that not a
>>> recommended method.
>>>
>>> Thanks
>>> Loya
>>>
>>
>>
>
>