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.

Primary Key Pool Table Problem

2 posts in General Discussion Last posting was on 2002-09-20 20:26:31.0Z
Mike_Hoar Posted on 2002-09-18 14:10:02.0Z
From: Mike_Hoar
Date: Wed, 18 Sep 2002 10:10:02 -0400
Newsgroups: ianywhere.public.general
Subject: Primary Key Pool Table Problem
Message-ID: <A75B9C19E1BE08BE004DD2E985256C38.004DD2F885256C38@webforums>
Lines: 25
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com!webforums.sybase.com!news
Xref: forums-1-dub ianywhere.public.general:608
Article PK: 2427

We have a product called Prospect (a customer management tool) which uses
an ASA 6 database, auto-increment primary key pools and Remote SQL. Its an
NT4 network at consolidated and Windows 2000 Server network at the remote.
The remote db has recently been going out of sink with the primary key
pools for two tables. At the remote we get to a point when one of the
Clients gets a duplicate primary key warning and no further records can be
entered. Looking at the primary key pool table at the remote the last
primary key value for the table is three or four numbers behind the primary
key values we have successfully written to the database via Prospect. At
consolidated all of the records entered at the remote have been replicated
through and the primary key pool table shows the correct last numbers for
the primary keys, ie everything looks okay. We have tried editing the
primary key pool table to reflect the actual primary last number but the
next row to be created the problem repeats itself. We end up reissuing
a block of primary key values to the remote to temporarily get over the
problem, it has happened three times now after something like 30-40 records
are entered or 3 or 4 days. I am not sure whether it is a replication
problem, may be not, but how can the auto-increment remote primary key
table get to be several numbers behind that of the current row primary key
value? I apologise if this only makes partial sense, I only have a basic
understanding of ASA and Remote SQL. We have two other remote db's each
serving several client workstations on an NT4 network, they work okay and
to me the set up looks the same.

Mike Hoar


Robert Waywell Posted on 2002-09-20 20:26:31.0Z
From: "Robert Waywell" <rwaywell@ianywhere.com>
References: <A75B9C19E1BE08BE004DD2E985256C38.004DD2F885256C38@webforums>
Subject: Re: Primary Key Pool Table Problem
Date: Fri, 20 Sep 2002 16:26:31 -0400
Lines: 65
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <Dbfy3XOYCHA.251@forums.sybase.com>
Newsgroups: ianywhere.public.general
NNTP-Posting-Host: 172.31.143.74
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub ianywhere.public.general:599
Article PK: 2414

I'd have to see how you have coded the key pool. Normally autoincrement
refers to an autoincrement default value on a column. That would not go
along with using a key pool.

I'd suggest following this up in the sybase.public.sqlanywhere.replication
newgroup. When you do that, you will need to provide details on how the key
values are generated at the consolidated, the publication used to distribute
the key values and how the key values are retrieved and used on the remote.

Alternatively you may want to open up a support case and work through
the issue with Tech Support.

--
-----------------------------------------------
Robert Waywell
Sybase Adaptive Server Anywhere Developer - Version 8
Sybase Certified Professional

Sybase's iAnywhere Solutions

Please respond ONLY to newsgroup

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports: http://casexpress.sybase.com/cx/cx.stm

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the iAnywhere
Developer Community at www.ianywhere.com/developer

<Mike_Hoar> wrote in message
news:A75B9C19E1BE08BE004DD2E985256C38.004DD2F885256C38@webforums...
> We have a product called Prospect (a customer management tool) which uses
> an ASA 6 database, auto-increment primary key pools and Remote SQL. Its an
> NT4 network at consolidated and Windows 2000 Server network at the remote.
> The remote db has recently been going out of sink with the primary key
> pools for two tables. At the remote we get to a point when one of the
> Clients gets a duplicate primary key warning and no further records can be
> entered. Looking at the primary key pool table at the remote the last
> primary key value for the table is three or four numbers behind the
primary
> key values we have successfully written to the database via Prospect. At
> consolidated all of the records entered at the remote have been
replicated
> through and the primary key pool table shows the correct last numbers for
> the primary keys, ie everything looks okay. We have tried editing the
> primary key pool table to reflect the actual primary last number but the
> next row to be created the problem repeats itself. We end up reissuing
> a block of primary key values to the remote to temporarily get over the
> problem, it has happened three times now after something like 30-40
records
> are entered or 3 or 4 days. I am not sure whether it is a replication
> problem, may be not, but how can the auto-increment remote primary key
> table get to be several numbers behind that of the current row primary key
> value? I apologise if this only makes partial sense, I only have a basic
> understanding of ASA and Remote SQL. We have two other remote db's each
> serving several client workstations on an NT4 network, they work okay and
> to me the set up looks the same.
>
> Mike Hoar