Post reply

Quick Question. Could be silly

  • February 11, 2010 at 1:40 pm

    #1117756

    _UB (2/11/2010)

    Thanks GSquared. I'll keep those questions in mind, while I think about a solution.

    Be it VM or not, the ID must be unique. Even if the database is transferred from one machine to the other the ID must not change. Something like a GUID that is stored in the user database. Like what SQLBOT suggested.

    thanks,

    _Uday

    In that case, I'd be inclined towards creating a CLR function that would work off of the MAC address of the machine the database is installed on, and the instance name.

    Even that might have problems with VMs. I'm not sure about that, but it would need to be investigated.

    Which brings up the question of how you'll deal with VMs that can move from server to server, or exist on multiple servers at the same time, etc. Will that matter? Do you change the "installation ID" if someone copies a VM to another server? How will you even know if that happens?

    Since I don't know your business-case for this, all I can do is suggest questions on these points. You'll have to work out if they matter or not.

    Just keep in mind that a GUID stored in a database can (and probably will) be copied. It will also be editable (though a hash or checksum can help make that prohibitively complicated.)

    Whether that matters or not will depend on what you need this for.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • February 11, 2010 at 2:05 pm

    #1117771

    Thanks, I'll keep that in mind.

    GSquared (2/11/2010)

    _UB (2/11/2010)

    Thanks GSquared. I'll keep those questions in mind, while I think about a solution.

    Be it VM or not, the ID must be unique. Even if the database is transferred from one machine to the other the ID must not change. Something like a GUID that is stored in the user database. Like what SQLBOT suggested.

    thanks,

    _Uday

    In that case, I'd be inclined towards creating a CLR function that would work off of the MAC address of the machine the database is installed on, and the instance name.

    Even that might have problems with VMs. I'm not sure about that, but it would need to be investigated.

    Which brings up the question of how you'll deal with VMs that can move from server to server, or exist on multiple servers at the same time, etc. Will that matter? Do you change the "installation ID" if someone copies a VM to another server? How will you even know if that happens?

    Since I don't know your business-case for this, all I can do is suggest questions on these points. You'll have to work out if they matter or not.

    Just keep in mind that a GUID stored in a database can (and probably will) be copied. It will also be editable (though a hash or checksum can help make that prohibitively complicated.)

    Whether that matters or not will depend on what you need this for.

    SqlTimes Blog on Sql Server

Viewing 2 posts - 16 through 16 (of 16 total)

You must be logged in to reply to this topic. Login to reply