Tim,

I understand not using an identity column as PK when doing replication.  It's a huge bag
of worms when you also consider the foreign keys that  would conflict as well.

What do you recommend using as a PK to avoid conflicts?  Also, how do you handle deleted
records during the replication?

Rob

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Rob,

<< Just wondering how you prevent record conflicts using your replication.
>>

Currently we are punting on the IDENTITY column issue, at least as far as
EDB providing any automatic solution.  Therefore, you'll have to include a
location identifier yourself if you wish to prevent conflicts of this
nature.

As far as conflicts in general are concerned, you will be allowed to define
a conflict handler that is like a trigger for dealing with conflicts and
taking the appropriate course of action.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

BTW, It sure would be nice to be able to specify an int64 column as a special type of PK
where the high part was the location number and the low part was an autoinc  (identity)
and have EDB generate this value automatically when a new record is added. This would
solve all conflict issues.

Rob

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Rob,

<< Just wondering how you prevent record conflicts using your replication.
>>

Currently we are punting on the IDENTITY column issue, at least as far as
EDB providing any automatic solution.  Therefore, you'll have to include a
location identifier yourself if you wish to prevent conflicts of this
nature.

As far as conflicts in general are concerned, you will be allowed to define
a conflict handler that is like a trigger for dealing with conflicts and
taking the appropriate course of action.

--
Tim Young
Elevate Software
www.elevatesoft.com

Rob,

<< What do you recommend using as a PK to avoid conflicts?  Also, how do you
handle deleted records during the replication? >>

Could you perhaps give me a few days before we get too far into this
discussion ?  I'm really pushing hard to get EDB 2.0 done right now, and
support requests are eating me alive.

Once the replication is done, I'll be happy to discuss how it all works.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<Could you perhaps give me a few days before we get too far into this
discussion ?  I'm really pushing hard to get EDB 2.0 done right now, and
support requests are eating me alive.

Once the replication is done, I'll be happy to discuss how it all works.>>

Here's hoping your EDB 2.0 efforts are proceeding well, Tim! Please take your time replying to this post -- I want you to focus on getting EDB 2.0
out the door

However, I thought I'd add my voice to the chorus of folks who are *very* interested in taking advantage of the new replication facility you're
building into 2.0. The timing of this is perfect as we are about to enter into the throes of migrating our mature DBISAM 3.x codebase to EDB 2.0
(bypassing DBISAM 4.x and EDB 1.0). From the outset, database replication was to be a big part of our Elevate-enabled product evolution.
Initially, I thought we'd have to roll our own replication logic -- but the discovery of this thread makes me believe I might just be able to invest
some of that "found" time into a wee bit of a vacation this year

When the time arrives Tim, how can I subscribe to be part of the [early] EDB 2.0 beta process?

Regards,
Jason Wilson
GlobeStar Systems

Jason,

<< When the time arrives Tim, how can I subscribe to be part of the [early]
EDB 2.0 beta process? >>

We're probably going to get this out into a final ASAP due to the
"already-too-long" delays.

--
Tim Young
Elevate Software
www.elevatesoft.com