What is s_GUID, s_ColLineage, s_Genertion, s_Lineage?

[Harold7]

Hello everyone,

I'm working on developing a very old database and some of the tables have these columns (s_GUID, s_ColLineage, s_Genertion, s_Lineage)

What are they, and is it okay to omit them when developing the database

Thanks

[CJ_London]

looks like they are replication fields. A method used in 2003 and earlier to synchronise data between master and slave db's. The method was discontinued in 2007 and not replaced with an alternative. The Master would spawn slave replica's that could be take 'off site' and changes made and on its return would be synchronised back the master.

There were problems - you couldn't sync one slave to another or to any other file but the master.

a GUID is a Global Unique IDentifier and you will find them in some of the system tables. And you can still set a PK as a GUID if you want, but not recommended - expensive as a resource (16 bytes v 4 bytes for an autonumber) and there are numerous things you can't do with a GUID that you can with an autonumber - can't remember what, it's been a long time since I experimented with them.

So you can delete them unless you are still using 2003 or earlier and need the functionality.

[Micron]

Being the cautious sort, I wouldn't delete them from the primary file until I tested the result in a copy of that file - just in case.

[Harold7]

looks like they are replication fields. A method used in 2003 and earlier to synchronise data between master and slave db's. The method was discontinued in 2007 and not replaced with an alternative. The Master would spawn slave replica's that could be take 'off site' and changes made and on its return would be synchronised back the master.

There were problems - you couldn't sync one slave to another or to any other file but the master.

a GUID is a Global Unique IDentifier and you will find them in some of the system tables. And you can still set a PK as a GUID if you want, but not recommended - expensive as a resource (16 bytes v 4 bytes for an autonumber) and there are numerous things you can't do with a GUID that you can with an autonumber - can't remember what, it's been a long time since I experimented with them.

So you can delete them unless you are still using 2003 or earlier and need the functionality.

I see.. I appreciate your help.

[Harold7]

Being the cautious sort, I wouldn't delete them from the primary file until I tested the result in a copy of that file - just in case.

Good idea, thanks.

[NoellaG]

When using replication, you need a GUID as PK. Using autonumbering you would have 1-2-3-... in every database, giving doubles trying to consolidate these in the master database. So you need a global unique ID field. Taking into consideration that we're talking of a primary key field here, I don't think it's a good idea to delete the GUID field when there are data in the database you want to keep.

[CJ_London]

When using replication, you need a GUID as PK.

strongly recommend you do not use a GUID as a PK, I experimented with the idea years ago and hit all sorts of problems. Use a separate field (autonumber - replicationID) solely for the purposes of replication/synchronising - together with two time fields, one to store the latest insert/update datetime in the master and one to store the latest insert/update datetime in the slave. If the former is later that the latter the slave needs updating, if the latter is later than the former, the master needs updating (and the slave updated to reflect the changed insert/update datetime in the master)

[NoellaG]

Using GUID's all the time, never had any problems with them. They are the simplest and best solution for replication purposes, don't complicate things with extra fields, it will only slow the engine down.

But as there is no more replication in Access and for this thread: only saying that if there exists a GUID as a primary key: don't delete the field. General rule: never delete the primary key field before you have made sure you replaced it with another PK field and tested this thoroughly.

[Micron]

FWIW, you can remove replication and maintain relationships. It may not be a widely posted topic but it's out there. I had to do it in order to work out a problem for someone else because the db was painfully slow on the old pc where I had an old version of Access that I could open it with.