|
Home > Archive > SQL Anywhere ultralite > September 2005 > Autoincrement on Numeric(8,0) [9.0.2.3137]
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Autoincrement on Numeric(8,0) [9.0.2.3137]
|
|
|
| This does not seem to be allowed in the schema painter. Am I doing
something wrong?
Also, side issue. Why does autoincrement use negative numbers on unsigned
data types in UL?
From manual...
"In UltraLite applications, the autoincrement value is not set to 0 when the
table is created, and AUTOINCREMENT generates negative numbers when a signed
data type is used for the column."
Is there an automated way to keep an autoincrement field unique when
disconnected from a remote database? Or should I be using global
autoincrement?
Sorry if this is documented somewhere...I couldn't find it.
rr
| |
| Greg Fenton 2005-09-24, 3:23 am |
| Please only post one question per thread, otherwise replies become very
hard to follow (also, you might not get answers from people who know the
answer to one question but not others).
rr12 wrote:
> This does not seem to be allowed in the schema painter. Am I doing
> something wrong?
This does appear to be a limitation of the schema painter. Please open
a case with iAnywhere Technical Support or post the repro steps to
CaseXpress (http://case-express.sybase.com).
> Also, side issue. Why does autoincrement use negative numbers on unsigned
> data types in UL?
If you use a signed type (e.g. INT, BIGINT) rather than an unsigned type
and the autoincrement value reaches the maximum positive value, then
autoincrement will generate negative values (in a number of programming
languages this is the case: (MAX_INTEGER + 1) <= 0).
So if you think you are going to "fill up" a column with MAX_INTEGER
values, then you should be using a different datatype (UNSIGNED INT,
BIGINT, UNSIGNED BIGINT, etc...). Besides, if you don't ever plan on
having negative numbers in the column, why would you even want to
declare it as a signed type??
>
> Is there an automated way to keep an autoincrement field unique when
> disconnected from a remote database? Or should I be using global
> autoincrement?
>
This is exactly the purpose to GLOBAL AUTOINCREMENT. Each database is
assigned a unique GLOBAL_DATABASE_ID that effectively assignes a unique
range of the values on the GLOBAL AUTOINCREMENT columns in the schema.
In a distributed environment, autoincrement can only be safely used at
the remotes as one part of a multi-column primary key (or of any unique
index).
Hope this helps,
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
| |
|
| Thank you. I just want to say that this newsgroup is great...very helpful.
Sorry for the multiple topics...I kind of realized that after I sent it.
I opened a case. It's nothing that I need immediately. My consolidated
database has a Numeric(8,0) autoincrement so I was just trying to have an
exact replication of that. However, that won't work anyway...So I've just
created a separate temporary autoincrement field which will not be used when
synched back with the consolidated db. Unfortunately, I can't change the
consolidated db and wont be able to use global autoincrement.
Thanks again.
rr12
"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:4334c802$1@foru
ms-2-dub...
> Please only post one question per thread, otherwise replies become very
> hard to follow (also, you might not get answers from people who know the
> answer to one question but not others).
>
> rr12 wrote:
>
> This does appear to be a limitation of the schema painter. Please open a
> case with iAnywhere Technical Support or post the repro steps to
> CaseXpress (http://case-express.sybase.com).
>
>
>
> If you use a signed type (e.g. INT, BIGINT) rather than an unsigned type
> and the autoincrement value reaches the maximum positive value, then
> autoincrement will generate negative values (in a number of programming
> languages this is the case: (MAX_INTEGER + 1) <= 0).
>
> So if you think you are going to "fill up" a column with MAX_INTEGER
> values, then you should be using a different datatype (UNSIGNED INT,
> BIGINT, UNSIGNED BIGINT, etc...). Besides, if you don't ever plan on
> having negative numbers in the column, why would you even want to declare
> it as a signed type??
>
>
> This is exactly the purpose to GLOBAL AUTOINCREMENT. Each database is
> assigned a unique GLOBAL_DATABASE_ID that effectively assignes a unique
> range of the values on the GLOBAL AUTOINCREMENT columns in the schema. In
> a distributed environment, autoincrement can only be safely used at the
> remotes as one part of a multi-column primary key (or of any unique
> index).
>
> Hope this helps,
> 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-09-26, 3:23 am |
| rr12 wrote:
> Unfortunately, I can't change the
> consolidated db and wont be able to use global autoincrement.
>
Not being able to change the consolidated does *not* limit you from
using GLOBAL AUTOINCREMENT. In fact, many of our customers use GLOBAL
AUTOINCREMENT without even having support for it in their consolidated's
RDBMS (remember, MobiLink synchronizes non-ASA consolidateds as well
such as ASE, Oracle, MSSQL and DB/2).
To do this, you essentially consider the consolidated as being assigned
a range of GLOBAL_DATABASE_IDs (e.g. 0 to 100) and then start assigning
GLOBAL_DATABASE_IDs to the remotes starting with, from this example, 101.
So on the consolidated, you can use whatever the
AUTOINCREMENT/SEQUENCE/IDENTITY feature you have for that particular
RDBMS, and for the remotes you use GLOBAL AUTOINCREMENT.
Also, just so you know, in our team we rarely (never?) use the Schema
Painter. We create a reference ASA database and use the ulinit tool to
generate the USM file. This way we can use normal database design
techniques (e.g. Power Designer, ERWin, SQL code).
Hope this helps,
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
| |
|
| Thanks. I guess I'm a little foggy on GLOBAL AUTOINCREMENT and
GLOBAL_DATABASE_ID. I'll check out the docs..
But I wanted to back up a little and find out if maybe I'm going about this
process all wrong. Here's what I'm doing...
I'm creating a UL.NET database application for PPC 2003 (and then Windows
Mobile 2005 after that) using VB.NET.
I have an existing version 7 ASA database. The UL.NET database will be a
very small subset of that database. Only about 10 tables and probably only
about half the columns in each table. (5-15 columns each).
The synchronization will be through ActiveSync. I'm creating SQL statements
(and procedures) in upload_insert, upload_update, etc. which will handle the
synchronization. I do that using Sybase Central. I've upgraded the
database to version 9 so I can set up mobilink.
I use the UL Schema painter to create my USM file as you know.
I don't own Powerdesigner or ERWin or any other db tools, other than SQL
Anywhere 9. So I don't have that option.
Am I going about this the best way? Or is there a better/easier way to go?
rr12
"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:43375d41$1@foru
ms-1-dub...
> rr12 wrote:
>
> Not being able to change the consolidated does *not* limit you from using
> GLOBAL AUTOINCREMENT. In fact, many of our customers use GLOBAL
> AUTOINCREMENT without even having support for it in their consolidated's
> RDBMS (remember, MobiLink synchronizes non-ASA consolidateds as well such
> as ASE, Oracle, MSSQL and DB/2).
>
> To do this, you essentially consider the consolidated as being assigned a
> range of GLOBAL_DATABASE_IDs (e.g. 0 to 100) and then start assigning
> GLOBAL_DATABASE_IDs to the remotes starting with, from this example, 101.
>
> So on the consolidated, you can use whatever the
> AUTOINCREMENT/SEQUENCE/IDENTITY feature you have for that particular
> RDBMS, and for the remotes you use GLOBAL AUTOINCREMENT.
>
> Also, just so you know, in our team we rarely (never?) use the Schema
> Painter. We create a reference ASA database and use the ulinit tool to
> generate the USM file. This way we can use normal database design
> techniques (e.g. Power Designer, ERWin, SQL code).
>
> Hope this helps,
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/
| |
| Joshua Savill 2005-09-26, 1:23 pm |
| This UltraLite Schema Painter problem has been resolved. This fix will
appear in EBF 3196 or higher for ASA 9.0.2
--
Joshua Savill
iAnywhere Solutions - Product Support Analyst
"rr12" <abc@123.com> wrote in message news:433578ae$1@foru
ms-1-dub...
> Thank you. I just want to say that this newsgroup is great...very
> helpful.
>
> Sorry for the multiple topics...I kind of realized that after I sent it.
>
> I opened a case. It's nothing that I need immediately. My consolidated
> database has a Numeric(8,0) autoincrement so I was just trying to have an
> exact replication of that. However, that won't work anyway...So I've just
> created a separate temporary autoincrement field which will not be used
> when synched back with the consolidated db. Unfortunately, I can't change
> the consolidated db and wont be able to use global autoincrement.
>
> Thanks again.
>
> rr12
>
>
> "Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
> news:4334c802$1@foru
ms-2-dub...
>
>
| |
|
| Ok. After looking at the docs I'm still confused about using global
autoincrement.
As a tiny example, if I have a Numeric(2,0) autoincrement column in my
consolidated database (which has a global_database_id of 0)...
....and then I create a remote database Numeric(2,0) global autoincrement
column in my remote database (which has a global_database_id of 5)...
....then what's going to happen?...
Isn't the consolidated going to start assigning values as 0,1,2,3, etc? And
then the remote is going to start assigning values 50,51,52,etc.
And then the consolidated will see 52 as the highest and start assigning
53,54,55 since it is not using any global_database_id or partition size in
it's logic?
I must not be getting it.
rr12
"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:43375d41$1@foru
ms-1-dub...
> rr12 wrote:
>
> Not being able to change the consolidated does *not* limit you from using
> GLOBAL AUTOINCREMENT. In fact, many of our customers use GLOBAL
> AUTOINCREMENT without even having support for it in their consolidated's
> RDBMS (remember, MobiLink synchronizes non-ASA consolidateds as well such
> as ASE, Oracle, MSSQL and DB/2).
>
> To do this, you essentially consider the consolidated as being assigned a
> range of GLOBAL_DATABASE_IDs (e.g. 0 to 100) and then start assigning
> GLOBAL_DATABASE_IDs to the remotes starting with, from this example, 101.
>
> So on the consolidated, you can use whatever the
> AUTOINCREMENT/SEQUENCE/IDENTITY feature you have for that particular
> RDBMS, and for the remotes you use GLOBAL AUTOINCREMENT.
>
> Also, just so you know, in our team we rarely (never?) use the Schema
> Painter. We create a reference ASA database and use the ulinit tool to
> generate the USM file. This way we can use normal database design
> techniques (e.g. Power Designer, ERWin, SQL code).
>
> Hope this helps,
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/
| |
|
| Thanks. I've just discovered that global autoincrement has the same problem
with a numeric(8,0).
Also, I know this does not belong here but I can't access the EBF download
page...
I get "Page not found" even after logging in. Where should I direct this
issue?
rr12
"Joshua Savill" <jsavill@ianywhere.com> wrote in message
news:43383b57@forums
-1-dub...
> This UltraLite Schema Painter problem has been resolved. This fix will
> appear in EBF 3196 or higher for ASA 9.0.2
>
> --
> Joshua Savill
> iAnywhere Solutions - Product Support Analyst
>
> "rr12" <abc@123.com> wrote in message news:433578ae$1@foru
ms-1-dub...
>
>
| |
| Greg Fenton 2005-09-26, 8:23 pm |
| rr12 wrote:
>
> ...and then I create a remote database Numeric(2,0) global autoincrement
> column in my remote database (which has a global_database_id of 5)...
>
[...]
>
> Isn't the consolidated going to start assigning values as 0,1,2,3, etc? And
> then the remote is going to start assigning values 50,51,52,etc.
>
The consolidated would start with values 1, 2, 3, ...
The remote is going to start at (pn + 1) and go up to p(n+1) where p is
the "partition size" and n is the global_database_id value. So in this
case, n=5 and p is determined by the partition size which by whatever
you set it to or as the default.
From the SQLAnywhere 9.x online docs:
MobiLink Clients
UltraLite Clients
Maintaining primary key uniqueness
- Declaring default global autoincrement columns
"For columns of type INT or UNSIGNED INT, the default partition size
is 216 = 65536; for columns of other types the default partition
size is 232 = 4294967296. Since these defaults may be inappropriate
it is best to specify the partition size explicitly."
So the first value to be inserted at your consolidated would be (5 *
4294967296 + 1), which is slightly larger than "99", the max value that
numeric(2,0) can hold.
So you have three options:
a) specify a partition size: DEFAULT GLOBAL AUTOINCREMENT(10)
b) use a larger value for your datatype definition: NUMERIC(20,0)
c) use a different datatype: UNSIGNED BIGINT
Using a NUMERIC to hold values that are integer (or whole number) values
is something I avoid. UNSIGNED INTEGER or UNSIGNED BIGINT is a better
description for those values, and I suspect there are performance
benefits to UNSIGNED BIGINT over NUMERIC(20,0) [though I don't have any
direct confirmation of that...]
I also strongly encourage all customers to specify the partition size
for their GLOBAL AUTOINCREMENT (except for in the case of BIGINT...in
which case the value is so large that it unlikely will ever be of
consequence). The case you have here of NUMERIC(2,0) is a perfect
example of why I stress this issue :-) [BTW: I hate defaults,
especially in source code and application configurations].
Hope this helps,
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-09-26, 8:23 pm |
| rr12 wrote:
> Thanks. I've just discovered that global autoincrement has the same problem
> with a numeric(8,0).
>
As an alternative, you might consider building a reference ASA database
and using the ulinit utility to generate the .USM. I think I posted
about this yesterday in this thead?
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
| |
|
| Ok. Yes, I was assuming partition size 10 for this hypothetical example...
....which would then start my remote global autoincrement values at 51, 52,
52...
What then happens to my autoincrement on the consolidated db after my next
synchronize? Isn't it going to start at 53 and potentially conflict?
(Unfortunately, I am not able to change any of the consolidated db's tables,
however inappropriate the data type.)
rr12
"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:43389d5f$1@foru
ms-1-dub...
> rr12 wrote:
>
> [...]
>
>
> The consolidated would start with values 1, 2, 3, ...
> The remote is going to start at (pn + 1) and go up to p(n+1) where p is
> the "partition size" and n is the global_database_id value. So in this
> case, n=5 and p is determined by the partition size which by whatever you
> set it to or as the default.
>
> From the SQLAnywhere 9.x online docs:
>
> MobiLink Clients
> UltraLite Clients
> Maintaining primary key uniqueness
> - Declaring default global autoincrement columns
>
> "For columns of type INT or UNSIGNED INT, the default partition size
> is 216 = 65536; for columns of other types the default partition
> size is 232 = 4294967296. Since these defaults may be inappropriate
> it is best to specify the partition size explicitly."
>
> So the first value to be inserted at your consolidated would be (5 *
> 4294967296 + 1), which is slightly larger than "99", the max value that
> numeric(2,0) can hold.
>
> So you have three options:
> a) specify a partition size: DEFAULT GLOBAL AUTOINCREMENT(10)
> b) use a larger value for your datatype definition: NUMERIC(20,0)
> c) use a different datatype: UNSIGNED BIGINT
>
> Using a NUMERIC to hold values that are integer (or whole number) values
> is something I avoid. UNSIGNED INTEGER or UNSIGNED BIGINT is a better
> description for those values, and I suspect there are performance benefits
> to UNSIGNED BIGINT over NUMERIC(20,0) [though I don't have any direct
> confirmation of that...]
>
> I also strongly encourage all customers to specify the partition size for
> their GLOBAL AUTOINCREMENT (except for in the case of BIGINT...in which
> case the value is so large that it unlikely will ever be of consequence).
> The case you have here of NUMERIC(2,0) is a perfect example of why I
> stress this issue :-) [BTW: I hate defaults, especially in source code
> and application configurations].
>
> Hope this helps,
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/
| |
| David Fishburn 2005-09-27, 7:23 am |
| "rr12" <abc@123.com> wrote in news:4338b926$1@foru
ms-1-dub of
sybase.public.sqlanywhere.ultralite:
rr12> Ok. Yes, I was assuming partition size 10 for this hypothetical
rr12> example...
rr12>
rr12> ...which would then start my remote global autoincrement values at
51,
rr12> 52, 52...
rr12>
rr12> What then happens to my autoincrement on the consolidated db after
my
rr12> next synchronize? Isn't it going to start at 53 and potentially
rr12> conflict?
That all depends.
If your consolidated is an ASA database which also specified:
id UNSIGNED INT GLOBAL AUTOINCREMENT (10)
Then no, it will not start at 51, it will continue to supply the next
highest value *within* the partition size alloted to that database.
If your consolidated is an Oracle database and you are using Oracle
sequence's, then in the sequence object you can specify the high and low
value. So this in this hypothetical case, you would have told the
sequence object to only generate values between 1 and 10.
--
David Fishburn
Certified ASA Developer Version 8
iAnywhere Solutions - Sybase
Professional Services
Please only post to the newsgroup
Please ALWAYS include version and MORE importantly BUILD number with
EACH post (dbeng9 -v).
EBFs and Maintenance Releases
http://downloads.sybase.com/swx/sdmain.stm
Developer Community / Whitepapers
http://www.ianywhere.com/developer
CaseXpress - to report bugs
http://casexpress.sybase.com
CodeXchange - Free samples
[url]http://ianywhere.codexchange.sybase.com/servlets/ ProjectDocumentList[
/url]
| |
| Greg Fenton 2005-09-27, 11:23 am |
| rr12 wrote:
>
> What then happens to my autoincrement on the consolidated db after my next
> synchronize? Isn't it going to start at 53 and potentially conflict?
>
Along with David's response, if you are using an ASA consolidated then
you can consider it to have a Very Large global_database_id. Use
sa_reset_identity() to set it's value to a Very Large value. All
inserts at the consolidated will be larger than this Very Large value,
while all remotes would have much smaller global_database_ids and
therefore insert much smaller values.
> (Unfortunately, I am not able to change any of the consolidated db's tables,
> however inappropriate the data type.)
Is using sa_reset_identity() against the cons an option?
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
| |
|
| Thank you for your responses. I appreciate them.
I'm asking what will happen given a certain set of assumptions and you guys
are both suggesting changing the assumptions.
My consolidated database is ASA. The column is autoincrement (not global
autoincrement). I can't change it.
Greg, you said I could use global autoincrement on the remotes for that
column.
From my understanding, the global autoincrement column (on the remote db)
would create values based on partition size and global database id. But
then after syncronization, the consolidated autoincrement (not global
autoincrement) column would just find the largest and add 1 to it; which
would generate a conflict.
Greg wrote, "Is using sa_reset_identity() against the cons an option?"
Why would this have any effect on an autoincrement (not global
autoincrement) column at the consolidated?
Sorry if I'm being argumentative here, just trying to figure this out.
rr12
"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:43395cd7$1@foru
ms-1-dub...
> rr12 wrote:
>
> Along with David's response, if you are using an ASA consolidated then you
> can consider it to have a Very Large global_database_id. Use
> sa_reset_identity() to set it's value to a Very Large value. All inserts
> at the consolidated will be larger than this Very Large value, while all
> remotes would have much smaller global_database_ids and therefore insert
> much smaller values.
>
>
> Is using sa_reset_identity() against the cons an option?
>
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/
| |
| David Kerber 2005-09-27, 1:23 pm |
| In article <43397cf6$1@forums-2-dub>, abc@123.com says...
....
> Greg wrote, "Is using sa_reset_identity() against the cons an option?"
>
> Why would this have any effect on an autoincrement (not global
> autoincrement) column at the consolidated?
Because then the consolidated would start at the new much higher number,
leaving room below it for the remotes to insert their data.
.....
--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
| |
|
| Ok. I see that now. I was missing the fact that the next value is based on
something outside the values themselves. Thanks.
I apoligize if I'm being dense.
"David Kerber" < ns_dkerber@ns_wraenv
iro.com> wrote in message
news:MPG. 1da34925c8f1e4169897
a6@forums.sybase.com...
> In article <43397cf6$1@forums-2-dub>, abc@123.com says...
>
> ...
>
>
> Because then the consolidated would start at the new much higher number,
> leaving room below it for the remotes to insert their data.
>
> ....
>
>
> --
> Remove the ns_ from if replying by e-mail (but keep posts in the
> newsgroups if possible).
| |
| Greg Fenton 2005-09-27, 8:23 pm |
| rr12 wrote:
> Ok. I see that now. I was missing the fact that the next value is based on
> something outside the values themselves. Thanks.
BTW: AUTOINCREMENT (and GLOBAL AUTOINCREMENT) do *not* look at the
largest value in the database and add 1 to it with each insert. The
database tracks the largest value inserted into an autoinc column and
maintains that value in a system table. Using sa_reset_identity(),
you
essentially change what the "highest value" seen for that column is.
If the column is UNSIGNED BIGINT, set the value in the cons to a Very
Large value (say, 9,223,372,036,854,77
5,807) and now the cons will only
insert values higher than that. When are remote synchs a much smaller
value (e.g. 100), it will not affect that columns maximum value. Taking
this approach means the consolidate has the range of 2^63 to (2^64 - 1).
With this approach, and using the default partition size, it means you
can have 2^31 remotes (that is, GLOBAL_DATABASE_IDs of 0 to
2,147,483,648) each being able to insert 2^32 values (4,294,967,296).
[Though, as I mentioned, I avoid default values in any code or
production environment...explicitly setting the range to the default
value is fine, but blindly relying on defaults is often a Bad Idea].
Hope this helps,
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
| |
|
| Yes, it helps a lot. The fog is lifting a little.
I'm with you on the defaults thing. Even if you are using the default
value, I think it's better to see that value being set so that the code is
self-documenting.
In my case, I can't use the default partition size anyway, since my column
is a Numeric(8,0).
The difficulty now is creating logic which will allow me to punch "holes" in
my range of values and bump up the next value with sa_reset_identity. The
column already exists and has values in it.
What I'm considering is just using (not global) autoincrement on the remotes
and then just discarding that value at the time of synchronization and let
the consolidated generate a new value. I'm not linked with any other tables
on that column so that should work ok.
But now I have a new problem with primary keys...I'll start a new post.
Thanks.
"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:433992e2$1@foru
ms-1-dub...
> rr12 wrote:
>
> BTW: AUTOINCREMENT (and GLOBAL AUTOINCREMENT) do *not* look at the largest
> value in the database and add 1 to it with each insert. The database
> tracks the largest value inserted into an autoinc column and maintains
> that value in a system table. Using sa_reset_identity(),
you essentially
> change what the "highest value" seen for that column is.
>
> If the column is UNSIGNED BIGINT, set the value in the cons to a Very
> Large value (say, 9,223,372,036,854,77
5,807) and now the cons will only
> insert values higher than that. When are remote synchs a much smaller
> value (e.g. 100), it will not affect that columns maximum value. Taking
> this approach means the consolidate has the range of 2^63 to (2^64 - 1).
> With this approach, and using the default partition size, it means you can
> have 2^31 remotes (that is, GLOBAL_DATABASE_IDs of 0 to 2,147,483,648)
> each being able to insert 2^32 values (4,294,967,296).
>
> [Though, as I mentioned, I avoid default values in any code or production
> environment...explicitly setting the range to the default value is fine,
> but blindly relying on defaults is often a Bad Idea].
>
> Hope this helps,
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/
|
|
|
|
|