Primary Key

I need to create my own primary key, how do I go about doing that?? In the database I am working in usually has a primary key that looks like this VL0008
the V is for Vendors, thats basically their number. Some of these Vendors need to be licensed and some dont, the ones that are not licensed dont get a number but I am to use that as the Primary/Index key I need to create one for those particual vendors. How can I go about doing that? I was wanting to make it TL888 something like that.what does "my own primary key" mean?

the table either has a primary key or it doesn't

if it doesn't, just create one

if it does, you have to remove that constraint before you define another column as the primary key|||I'm more than a little confused. A primary key can be any datatype that supports enough unique values for each row of interest to have exactly one value for the primary key. Most of the folks here like to use integers, although everybody is free to use their own preference (distributed apps like GUIDs, most legacy apps seem to like CHAR, whatever works...).

I'd suggest picking the whatever datatype suits you, and simply using it. I would avoid anything that needs specific formatting, these often cause more problems than they solve. Most of the folks here like to use an int with an IDENTITY attribute.

To add a PK value to table BigFatMess, you could use something like:ALTER TABLE BigFatMess
ADD BigFatMessId INT IDENTITY (-2147483648, 1)
CONSTRAINT XPKBigFatMess
PRIMARY KEY (BigFatMessId)-PatP|||I think she is looking for a way to auto-generate alphanumeric keys (which could then be used as a primary key...).

You could try creating an incrementing identity field in your table to create the numeric portion and then have a calculated field that prepends your alphabetic string.

But you should think about WHY you want this and WHAT you are going to do with it. Frankly, a code such as "TL888" is not as usefull as two separate columns for storing the "TL" and "888" portions, because as a single value you will need to apply character functions to it to parse out and use its components and you will lose the benefit of indexes.|||Yes Blindman thats exactly what I am trying to do thank you

I'm sorry guys I'm doing a poor job of explaining myself.|||So is your issue resolved?|||I think she is looking for a way to auto-generate alphanumeric keys (which could then be used as a primary key...).

And why wouldn't a composite key do the same thing?|||I have found another solution, thanks for your help though I appreciate it

Preventing customers from hacking my MSDE database?

Recently I installed a commercial client-only product utilizing an
MSDE database.
The product installed its own instance of MSDE rather than adding a
database to the default instance (or install a default instance).
Of course, not with a blank sa password, so I could not access it
just by firing up Enterprise Manager or Query Analyzer.
Still, I was curious about the structure of the database, so
all I had to do to gain access to the table structure and data was to
stop the service for the MSDE instance, locate the database and log
files, copy them to another location, and attach them to the default
instance. I now had access to the table structure and all the data.
Still, the triggers and stored procedures were stored with encryption,
but this was no problem for a tool like Orbital's SQL Decryptor or a
couple of other scripts freely available on the Internet.
Question is: Is there anything the author could have done to prevent
me from doing any of the above? Or to put it another way: Is there
anything I can do to prevent others from accessing data in my own
programs in unauthorized ways?
TIA,
JBHave you tried to remove the user from System Admin server role and give
them an appropriate permissions?
"Joergen Bech @. post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:cjdpn0hjt5dtilasl28hg29g9qt76c0v5o@.
4ax.com...
> Recently I installed a commercial client-only product utilizing an
> MSDE database.
> The product installed its own instance of MSDE rather than adding a
> database to the default instance (or install a default instance).
> Of course, not with a blank sa password, so I could not access it
> just by firing up Enterprise Manager or Query Analyzer.
> Still, I was curious about the structure of the database, so
> all I had to do to gain access to the table structure and data was to
> stop the service for the MSDE instance, locate the database and log
> files, copy them to another location, and attach them to the default
> instance. I now had access to the table structure and all the data.
> Still, the triggers and stored procedures were stored with encryption,
> but this was no problem for a tool like Orbital's SQL Decryptor or a
> couple of other scripts freely available on the Internet.
> Question is: Is there anything the author could have done to prevent
> me from doing any of the above? Or to put it another way: Is there
> anything I can do to prevent others from accessing data in my own
> programs in unauthorized ways?
> TIA,
> JB
>
>|||Basically no. If it is installed on their server then most likely they will
have the ability to access your files and or the db directly. Your best
recourse is to have very good copywrite, NDA's etc. in place.
Andrew J. Kelly SQL MVP
"Joergen Bech @. post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:cjdpn0hjt5dtilasl28hg29g9qt76c0v5o@.
4ax.com...
> Recently I installed a commercial client-only product utilizing an
> MSDE database.
> The product installed its own instance of MSDE rather than adding a
> database to the default instance (or install a default instance).
> Of course, not with a blank sa password, so I could not access it
> just by firing up Enterprise Manager or Query Analyzer.
> Still, I was curious about the structure of the database, so
> all I had to do to gain access to the table structure and data was to
> stop the service for the MSDE instance, locate the database and log
> files, copy them to another location, and attach them to the default
> instance. I now had access to the table structure and all the data.
> Still, the triggers and stored procedures were stored with encryption,
> but this was no problem for a tool like Orbital's SQL Decryptor or a
> couple of other scripts freely available on the Internet.
> Question is: Is there anything the author could have done to prevent
> me from doing any of the above? Or to put it another way: Is there
> anything I can do to prevent others from accessing data in my own
> programs in unauthorized ways?
> TIA,
> JB
>
>