Kim,

<< No, in Advantage you can exclude columns. I do not replicate AutoInc columns I let the receiving table assign an Integer to the column. >>

Whoa, wait a second.  Is the AutoInc column the primary/unique key for the table ?  *That* is the issue with using IDENTITY columns as primary keys with replication in ElevateDB.  It's not that you can't ignore them or do what you're describing, it's just that they're often used as the primary key column, and the primary key is what ElevateDB uses to perform replication.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

Whoa, wait a second.  Is the AutoInc column the primary/unique key for the table ?  *That* is the issue with using IDENTITY columns as primary keys with replication in ElevateDB.  It's not that you can't ignore them or do what you're describing, it's just that they're often used as the primary key column, and the primary key is what ElevateDB uses to perform replication.

No It's not the primary key, ( in Advantage you don't need to use the Primary Key you can set any column that have a unique key to be the primary key for the replication) I use it to be sure records shows in the order they were entered.

Example I have 10 stores that replicate one table to one table on the server. Each of those store have the autoinc on one column, I exclude that column and as the 10 tables records get inserted in the one table it get assign a new auotoinc.

Kim

Kim,

<< No It's not the primary key, ( in Advantage you don't need to use the Primary Key you can set any column that have a unique key to be the primary key for the replication) I use it to be sure records shows in the order they were entered. >>

You don't need that with ElevateDB.  ElevateDB *always* orders rows by an internal, incrementing row ID in the absence of any other ordering.  In other words, if you are viewing a table in a "State" index order and there are, of course, multiple rows with the same State column value, then the ordering *within* each state will be according to this internal row ID.

You can actually retrieve this row ID like this:

SELECT __RowID FROM MyTable

<< Example I have 10 stores that replicate one table to one table on the server. Each of those store have the autoinc on one column, I exclude that column and as the 10 tables records get inserted in the one table it get assign a new auotoinc. >>

Yes, you don't need this anymore.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

<<You don't need that with ElevateDB.  ElevateDB *always* orders rows by an internal, incrementing row ID in the absence of any other ordering.  In other words, if you are viewing a table in a "State" index order and there are, of course, multiple rows with the same State column value, then the ordering *within* each state will be according to this internal row ID.

You can actually retrieve this row ID like this:

SELECT __RowID FROM MyTable >>

Advantage Database would reuse deleted rows so it would not be in order.

Kim

KimHJ


>Advantage Database would reuse deleted rows so it would not be in order.

Unless its been changed when I wasn't looking I think ElevateDB reuses deleted rows - that's one reason why __RowID is needed

Roy Lambert

Kim,

<< Advantage Database would reuse deleted rows so it would not be in order. >>

In EDB, the row # is not the same thing as the row ID.  The row ID is an ever-incrementing ID value that EDB uses to uniquely distinguish one row from another for the purposes of ordering rows with the same key values.  It actually uses *another* internal ever-incrementing value for the "version" of a row, but that's another story...

Tim Young
Elevate Software
www.elevatesoft.com