MS SQL: syntax error in create table sql

Using Management Studio (for MS SQL server 8) I had created a table, given a primary key and created a unique key.
I then had the management studio "script 'create' to file" and it saved an SQL statement (below).
I then dropped/deleted the table and tried to execute the creation statement.
It says "Incorrect syntax near '('. " and references the block connected with the "WITH" statement. (Actually both of them cause the error and removing them gets rid of it.
Is there a way to keep the information contained in the WITH statement in my table creation SQL? Is it even required info?

Code: ( sql )

USE [MyProducts]GO/****** Object: Table [dbo].[Category] Script Date: 10/12/2007 11:22:52 ******/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOSET ANSI_PADDING ONGOCREATE TABLE [dbo].[Category]( [CategoryID] [int] IDENTITY(1,1) NOT NULL, [Name] [varchar](50) NOT NULL, [CategoryNumber] [int] NOT NULL, [ModifiedDate] [datetime] NOT NULL, CONSTRAINT [PK_Category] PRIMARY KEY CLUSTERED ( [CategoryID] ASC ) WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON ) ON [PRIMARY], CONSTRAINT [IX_UniqueCategoryNumber] UNIQUE NONCLUSTERED ( [CategoryNumber] ASC ) WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON ) ON [PRIMARY]) ON [PRIMARY] GOSET ANSI_PADDING OFF

Usually you never use With statement while creating a table.

Remove this statement and create table without it then go to table definition and see it should be picked by default.

Good Luck.|||it "appeared" to create correctly without the WITH statements.
I was just bothered by the management studio auto-createing the statement then telling my there were syntax errors. The msdn help on the T-SQL for it shows WITH statements in the smae style.
All well, I'll just remove them.

Thanks.|||You can change some settings but not all.
Most of them are server level settings and can not be changed and just read only.

For example you see ON [PRIMARY] and it allows you to put data on one device and indexes on different devices or even spread tables among several devices but server should see your other devices first before you are trying to create something on them. So it is available but for people who know what they doing
You are doing grate so good luck.

MS SQL SP3a installation failure

Dear experts!
I have MS SQL 2000 on the PC running Windows 2000 Server.
The MDAC version is 2.8, the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\Co
nnectTo\DSQUERY (REG_SZ)is set to DBNETLIB
The key NtfsDisable8dot3NameCreation under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSys
tem\ is set to 0, the user's variables TMP and TEMP are
set to c:\temp
The SP3a still fails while installation with the following
error messages:
"setup was unable to validate the password" and "setup was
unable to verify the state of the server for an upgrade"
If you know the solution please help to resolve the
problem.
Regards,
Elena.Refer to:
http://support.microsoft.com/default.aspx?scid=kb;en-us;814844
And here is a similar workaround applied to SP2
http://support.microsoft.com/default.aspx?scid=kb;en-us;328290
--
- Anith
( Please reply to newsgroups only )|||All the requirements listed in those articles have been
already met. But it does not work
Regards,
Elena.

ms sql server 2000 too weak ?

It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
PemBukuan.Com
http://www.as3000.com
RW,
Security in general is said to start with the physical box - once this is
compromised then there's little you can do (eg Linux can be used to bypass
NTFS so file system security doesn't help). SQL Server security itself is
based on logins, users and permissions/roles, all of which exist in the
database file, so, after the box is accessed (compromised), someone needs to
be able to access/compromise the file.
There's no simple solution apart from securing the box and the files; you
can password protect your backups but not the datafiles.
Regards,
Paul Ibison
|||Why not MS add an additional physics login password as an option ? just
like what we have in excel, word, access ? I know that kind of password
is too simple, they can build a more advance password, I think may be
they don't want to take the risk of while users forget the password.
If developer want to distribute an application with safe and small
capacity database, then I think the MSDE is not a choice.
Paul Ibison wrote:
> RW,
> Security in general is said to start with the physical box - once this is
> compromised then there's little you can do (eg Linux can be used to bypass
> NTFS so file system security doesn't help). SQL Server security itself is
> based on logins, users and permissions/roles, all of which exist in the
> database file, so, after the box is accessed (compromised), someone needs to
> be able to access/compromise the file.
> There's no simple solution apart from securing the box and the files; you
> can password protect your backups but not the datafiles.
> Regards,
> Paul Ibison
sql

ms sql server 2000 too weak ?

It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
--
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.comRW,
Security in general is said to start with the physical box - once this is
compromised then there's little you can do (eg Linux can be used to bypass
NTFS so file system security doesn't help). SQL Server security itself is
based on logins, users and permissions/roles, all of which exist in the
database file, so, after the box is accessed (compromised), someone needs to
be able to access/compromise the file.
There's no simple solution apart from securing the box and the files; you
can password protect your backups but not the datafiles.
Regards,
Paul Ibison|||Why not MS add an additional physics login password as an option ? just
like what we have in excel, word, access ? I know that kind of password
is too simple, they can build a more advance password, I think may be
they don't want to take the risk of while users forget the password.
If developer want to distribute an application with safe and small
capacity database, then I think the MSDE is not a choice.
Paul Ibison wrote:
> RW,
> Security in general is said to start with the physical box - once this is
> compromised then there's little you can do (eg Linux can be used to bypass
> NTFS so file system security doesn't help). SQL Server security itself is
> based on logins, users and permissions/roles, all of which exist in the
> database file, so, after the box is accessed (compromised), someone needs to
> be able to access/compromise the file.
> There's no simple solution apart from securing the box and the files; you
> can password protect your backups but not the datafiles.
> Regards,
> Paul Ibison
--

ms sql server 2000 too weak ?

It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.comRW,
Security in general is said to start with the physical box - once this is
compromised then there's little you can do (eg Linux can be used to bypass
NTFS so file system security doesn't help). SQL Server security itself is
based on logins, users and permissions/roles, all of which exist in the
database file, so, after the box is accessed (compromised), someone needs to
be able to access/compromise the file.
There's no simple solution apart from securing the box and the files; you
can password protect your backups but not the datafiles.
Regards,
Paul Ibison|||Why not MS add an additional physics login password as an option ? just
like what we have in excel, word, access ? I know that kind of password
is too simple, they can build a more advance password, I think may be
they don't want to take the risk of while users forget the password.
If developer want to distribute an application with safe and small
capacity database, then I think the MSDE is not a choice.
Paul Ibison wrote:
> RW,
> Security in general is said to start with the physical box - once this is
> compromised then there's little you can do (eg Linux can be used to bypass
> NTFS so file system security doesn't help). SQL Server security itself is
> based on logins, users and permissions/roles, all of which exist in the
> database file, so, after the box is accessed (compromised), someone needs
to
> be able to access/compromise the file.
> There's no simple solution apart from securing the box and the files; you
> can password protect your backups but not the datafiles.
> Regards,
> Paul Ibison

ms sql server 2000 security too weak ?

It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.com"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||1. using NTFS security still allow to get in, and duplicate the
database, this is not why I mean, but they can copy and open it in
another server without any protection.
2. using data encryption of course will slow down the performance while
we process large amount of data
I am not blaming MS, actually the sql server is quite a good and easy to
maintain database, only we are so curious, why other user data like
excel spreadsheet, word, access can have their own password, and
specially the most important data container (sql server) open like a
mall and welcome in, u just login in as 'sa' and u get everything.
Why not MS add an additional login password as an option, may be that's
much better than let it open.

> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
> b.t.w. there is nearly no protection against harddisk access by a
> technician. You can't blame MS for that. But data encryption by the
> application that uses MSDE is a solution...|||"RW" <goldbase@.centrin.net.id> wrote in message
news:407AB799.4F6F@.centrin.net.id...
> 1. using NTFS security still allow to get in, and duplicate the
> database, this is not why I mean, but they can copy and open it in
> another server without any protection.
> 2. using data encryption of course will slow down the performance while
> we process large amount of data
see below...

> I am not blaming MS, actually the sql server is quite a good and easy to
> maintain database, only we are so curious, why other user data like
> excel spreadsheet, word, access can have their own password, and
> specially the most important data container (sql server) open like a
> mall and welcome in, u just login in as 'sa' and u get everything.
> Why not MS add an additional login password as an option, may be that's
> much better than let it open.
Applying a single password is really a nope-operation. for instance, SQL
stored procs can be encrypted, but they can be decripted using 'tools' that
are available on the net.
So that's why the 'slow' operation, that is a 3 key-algorithm
(public/private/session) is the ONLY viable solution to safegard a file. A
single password with 'xor' encryption on a file is as explained, useless.
Cheers,|||hi
what is necessary to do for encrypt data?
atte,
Hernn Castelo
UTN Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . .
.
"Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en el
mensaje
news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||> "Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en
el mensaje
> news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:4079FBD2.559B@.centrin.net.id...
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
"Hernn Castelo" <hhh@.hotmail.com> wrote in message
news:%23KshfkMIEHA.3476@.TK2MSFTNGP11.phx.gbl...
> hi
> what is necessary to do for encrypt data?
> --
> atte,
> Hernn Castelo
> UTN Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . . .
.
Your application can encrypt data. If you have .NET you can use Rijnhaeve
(If I spell correctly) and such. .NET samples show how to do it.
With C++ (7.0 and higher) there are encryption templates as well.|||You didn't get my question, what I mean is if your database which you
have protect with the algorithm and re-install by somebody in their
server, then all your data will be seen and access using their 'sa'
login, so where's the protection ?
Egbert Nierop (MVP for IIS) wrote:
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407AB799.4F6F@.centrin.net.id...
> see below...
>
> Applying a single password is really a nope-operation. for instance, SQL
> stored procs can be encrypted, but they can be decripted using 'tools' tha
t
> are available on the net.
> So that's why the 'slow' operation, that is a 3 key-algorithm
> (public/private/session) is the ONLY viable solution to safegard a file. A
> single password with 'xor' encryption on a file is as explained, useless.
> Cheers,|||If the user is an administrator of the SQL Server, then they can steal your
MDF files. But then, they can do anything anyway.
If the user is an administrator of the Windows machine that SQL Server is
on, then they can steal everything on the server anyway.
Normal users can not do this.
So, you need to trust your administrators.
Anyway, even if there was a "separate" password, how would your applications
access the database? They would need the password, which means it has to be
stored somewhere, which means the administrator could steal it from there
(eg from the client application, or by monitoring the traffic that goes into
SQL Server).
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~
"RW" <goldbase@.centrin.net.id> wrote in message
news:407B4E73.682C@.centrin.net.id...
: You didn't get my question, what I mean is if your database which you
: have protect with the algorithm and re-install by somebody in their
: server, then all your data will be seen and access using their 'sa'
: login, so where's the protection ?
:
:
:
: Egbert Nierop (MVP for IIS) wrote:
: >
: > "RW" <goldbase@.centrin.net.id> wrote in message
: > news:407AB799.4F6F@.centrin.net.id...
: > > 1. using NTFS security still allow to get in, and duplicate the
: > > database, this is not why I mean, but they can copy and open it in
: > > another server without any protection.
: > >
: > > 2. using data encryption of course will slow down the performance
while
: > > we process large amount of data
: >
: > see below...
: >
: > > I am not blaming MS, actually the sql server is quite a good and easy
to
: > > maintain database, only we are so curious, why other user data like
: > > excel spreadsheet, word, access can have their own password, and
: > > specially the most important data container (sql server) open like a
: > > mall and welcome in, u just login in as 'sa' and u get everything.
: > >
: > > Why not MS add an additional login password as an option, may be
that's
: > > much better than let it open.
: >
: > Applying a single password is really a nope-operation. for instance, SQL
: > stored procs can be encrypted, but they can be decripted using 'tools'
that
: > are available on the net.
: > So that's why the 'slow' operation, that is a 3 key-algorithm
: > (public/private/session) is the ONLY viable solution to safegard a file.
A
: > single password with 'xor' encryption on a file is as explained,
useless.
: >
: > Cheers,
:|||Sometimes trusting people too full is risky to the company, it should be
a double checking procedure and control by two authorized person.
About the monitoring data traffic is not very easy do that if the
application using a native database driver, except ODBC.
My suggestion is when attaching the MDF files will require the original
serial number of ms.sql server 2000 where it was created, I think at
least this is another way to protect the MDF files, even somebody or the
kick out administrator copy it, then it's useless, they should know the
serial number to access the MDF.
What do you think ?
brgs,
Ridwan
Ken Schaefer wrote:
> If the user is an administrator of the SQL Server, then they can steal you
r
> MDF files. But then, they can do anything anyway.
> If the user is an administrator of the Windows machine that SQL Server is
> on, then they can steal everything on the server anyway.
> Normal users can not do this.
> So, you need to trust your administrators.
> Anyway, even if there was a "separate" password, how would your applicatio
ns
> access the database? They would need the password, which means it has to b
e
> stored somewhere, which means the administrator could steal it from there
> (eg from the client application, or by monitoring the traffic that goes in
to
> SQL Server).
> Cheers
> Ken
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407B4E73.682C@.centrin.net.id...
> : You didn't get my question, what I mean is if your database which you
> : have protect with the algorithm and re-install by somebody in their
> : server, then all your data will be seen and access using their 'sa'
> : login, so where's the protection ?
> :
> :
> :
> : Egbert Nierop (MVP for IIS) wrote:
> : >
> : > "RW" <goldbase@.centrin.net.id> wrote in message
> : > news:407AB799.4F6F@.centrin.net.id...
> : > > 1. using NTFS security still allow to get in, and duplicate the
> : > > database, this is not why I mean, but they can copy and open it in
> : > > another server without any protection.
> : > >
> : > > 2. using data encryption of course will slow down the performance
> while
> : > > we process large amount of data
> : >
> : > see below...
> : >
> : > > I am not blaming MS, actually the sql server is quite a good and eas
y
> to
> : > > maintain database, only we are so curious, why other user data like
> : > > excel spreadsheet, word, access can have their own password, and
> : > > specially the most important data container (sql server) open like a
> : > > mall and welcome in, u just login in as 'sa' and u get everything.
> : > >
> : > > Why not MS add an additional login password as an option, may be
> that's
> : > > much better than let it open.
> : >
> : > Applying a single password is really a nope-operation. for instance, S
QL
> : > stored procs can be encrypted, but they can be decripted using 'tools'
> that
> : > are available on the net.
> : > So that's why the 'slow' operation, that is a 3 key-algorithm
> : > (public/private/session) is the ONLY viable solution to safegard a fil
e.
> A
> : > single password with 'xor' encryption on a file is as explained,
> useless.
> : >
> : > Cheers,
> :|||> what is necessary to do for encrypt data?
>
Checkout www.database-encryption.com
www.sql-shield.com

ms sql server 2000 security too weak ?

It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
--
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.com"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||1. using NTFS security still allow to get in, and duplicate the
database, this is not why I mean, but they can copy and open it in
another server without any protection.
2. using data encryption of course will slow down the performance while
we process large amount of data
I am not blaming MS, actually the sql server is quite a good and easy to
maintain database, only we are so curious, why other user data like
excel spreadsheet, word, access can have their own password, and
specially the most important data container (sql server) open like a
mall and welcome in, u just login in as 'sa' and u get everything.
Why not MS add an additional login password as an option, may be that's
much better than let it open.
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
> b.t.w. there is nearly no protection against harddisk access by a
> technician. You can't blame MS for that. But data encryption by the
> application that uses MSDE is a solution...|||"RW" <goldbase@.centrin.net.id> wrote in message
news:407AB799.4F6F@.centrin.net.id...
> 1. using NTFS security still allow to get in, and duplicate the
> database, this is not why I mean, but they can copy and open it in
> another server without any protection.
> 2. using data encryption of course will slow down the performance while
> we process large amount of data
see below...
> I am not blaming MS, actually the sql server is quite a good and easy to
> maintain database, only we are so curious, why other user data like
> excel spreadsheet, word, access can have their own password, and
> specially the most important data container (sql server) open like a
> mall and welcome in, u just login in as 'sa' and u get everything.
> Why not MS add an additional login password as an option, may be that's
> much better than let it open.
Applying a single password is really a nope-operation. for instance, SQL
stored procs can be encrypted, but they can be decripted using 'tools' that
are available on the net.
So that's why the 'slow' operation, that is a 3 key-algorithm
(public/private/session) is the ONLY viable solution to safegard a file. A
single password with 'xor' encryption on a file is as explained, useless.
Cheers,|||hi
what is necessary to do for encrypt data?
--
atte,
Hernán Castelo
UTN Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . . .
"Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribió en el mensaje
news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||> "Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribió en
el mensaje
> news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:4079FBD2.559B@.centrin.net.id...
> > It seems the authority for DBA is too much to control the safety of .mdf
> > , why not add an additional password or key to protect it, if someone
> > copy the .mdf files and install to a new sql server service, they can
> > read everything using sa facility, is it worse than ms.access ?
> >
> > at least ms.access still need some extra job to crack it, but the .mdf
> > is too simple, just copy and read it.
> >
> > Especially the MSDE version in one single computer, even the hardware
> > technician can duplicate and sell your important data.
> >
> > Anyone have solution for this security problem ?
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
"Hernán Castelo" <hhh@.hotmail.com> wrote in message
news:%23KshfkMIEHA.3476@.TK2MSFTNGP11.phx.gbl...
> hi
> what is necessary to do for encrypt data?
> --
> atte,
> Hernán Castelo
> UTN Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . . .
.
Your application can encrypt data. If you have .NET you can use Rijnhaeve
(If I spell correctly) and such. .NET samples show how to do it.
With C++ (7.0 and higher) there are encryption templates as well.|||You didn't get my question, what I mean is if your database which you
have protect with the algorithm and re-install by somebody in their
server, then all your data will be seen and access using their 'sa'
login, so where's the protection ?
Egbert Nierop (MVP for IIS) wrote:
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407AB799.4F6F@.centrin.net.id...
> > 1. using NTFS security still allow to get in, and duplicate the
> > database, this is not why I mean, but they can copy and open it in
> > another server without any protection.
> >
> > 2. using data encryption of course will slow down the performance while
> > we process large amount of data
> see below...
> > I am not blaming MS, actually the sql server is quite a good and easy to
> > maintain database, only we are so curious, why other user data like
> > excel spreadsheet, word, access can have their own password, and
> > specially the most important data container (sql server) open like a
> > mall and welcome in, u just login in as 'sa' and u get everything.
> >
> > Why not MS add an additional login password as an option, may be that's
> > much better than let it open.
> Applying a single password is really a nope-operation. for instance, SQL
> stored procs can be encrypted, but they can be decripted using 'tools' that
> are available on the net.
> So that's why the 'slow' operation, that is a 3 key-algorithm
> (public/private/session) is the ONLY viable solution to safegard a file. A
> single password with 'xor' encryption on a file is as explained, useless.
> Cheers,|||If the user is an administrator of the SQL Server, then they can steal your
MDF files. But then, they can do anything anyway.
If the user is an administrator of the Windows machine that SQL Server is
on, then they can steal everything on the server anyway.
Normal users can not do this.
So, you need to trust your administrators.
Anyway, even if there was a "separate" password, how would your applications
access the database? They would need the password, which means it has to be
stored somewhere, which means the administrator could steal it from there
(eg from the client application, or by monitoring the traffic that goes into
SQL Server).
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"RW" <goldbase@.centrin.net.id> wrote in message
news:407B4E73.682C@.centrin.net.id...
: You didn't get my question, what I mean is if your database which you
: have protect with the algorithm and re-install by somebody in their
: server, then all your data will be seen and access using their 'sa'
: login, so where's the protection ?
:
:
:
: Egbert Nierop (MVP for IIS) wrote:
: >
: > "RW" <goldbase@.centrin.net.id> wrote in message
: > news:407AB799.4F6F@.centrin.net.id...
: > > 1. using NTFS security still allow to get in, and duplicate the
: > > database, this is not why I mean, but they can copy and open it in
: > > another server without any protection.
: > >
: > > 2. using data encryption of course will slow down the performance
while
: > > we process large amount of data
: >
: > see below...
: >
: > > I am not blaming MS, actually the sql server is quite a good and easy
to
: > > maintain database, only we are so curious, why other user data like
: > > excel spreadsheet, word, access can have their own password, and
: > > specially the most important data container (sql server) open like a
: > > mall and welcome in, u just login in as 'sa' and u get everything.
: > >
: > > Why not MS add an additional login password as an option, may be
that's
: > > much better than let it open.
: >
: > Applying a single password is really a nope-operation. for instance, SQL
: > stored procs can be encrypted, but they can be decripted using 'tools'
that
: > are available on the net.
: > So that's why the 'slow' operation, that is a 3 key-algorithm
: > (public/private/session) is the ONLY viable solution to safegard a file.
A
: > single password with 'xor' encryption on a file is as explained,
useless.
: >
: > Cheers,
:|||Sometimes trusting people too full is risky to the company, it should be
a double checking procedure and control by two authorized person.
About the monitoring data traffic is not very easy do that if the
application using a native database driver, except ODBC.
My suggestion is when attaching the MDF files will require the original
serial number of ms.sql server 2000 where it was created, I think at
least this is another way to protect the MDF files, even somebody or the
kick out administrator copy it, then it's useless, they should know the
serial number to access the MDF.
What do you think ?
brgs,
Ridwan
Ken Schaefer wrote:
> If the user is an administrator of the SQL Server, then they can steal your
> MDF files. But then, they can do anything anyway.
> If the user is an administrator of the Windows machine that SQL Server is
> on, then they can steal everything on the server anyway.
> Normal users can not do this.
> So, you need to trust your administrators.
> Anyway, even if there was a "separate" password, how would your applications
> access the database? They would need the password, which means it has to be
> stored somewhere, which means the administrator could steal it from there
> (eg from the client application, or by monitoring the traffic that goes into
> SQL Server).
> Cheers
> Ken
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407B4E73.682C@.centrin.net.id...
> : You didn't get my question, what I mean is if your database which you
> : have protect with the algorithm and re-install by somebody in their
> : server, then all your data will be seen and access using their 'sa'
> : login, so where's the protection ?
> :
> :
> :
> : Egbert Nierop (MVP for IIS) wrote:
> : >
> : > "RW" <goldbase@.centrin.net.id> wrote in message
> : > news:407AB799.4F6F@.centrin.net.id...
> : > > 1. using NTFS security still allow to get in, and duplicate the
> : > > database, this is not why I mean, but they can copy and open it in
> : > > another server without any protection.
> : > >
> : > > 2. using data encryption of course will slow down the performance
> while
> : > > we process large amount of data
> : >
> : > see below...
> : >
> : > > I am not blaming MS, actually the sql server is quite a good and easy
> to
> : > > maintain database, only we are so curious, why other user data like
> : > > excel spreadsheet, word, access can have their own password, and
> : > > specially the most important data container (sql server) open like a
> : > > mall and welcome in, u just login in as 'sa' and u get everything.
> : > >
> : > > Why not MS add an additional login password as an option, may be
> that's
> : > > much better than let it open.
> : >
> : > Applying a single password is really a nope-operation. for instance, SQL
> : > stored procs can be encrypted, but they can be decripted using 'tools'
> that
> : > are available on the net.
> : > So that's why the 'slow' operation, that is a 3 key-algorithm
> : > (public/private/session) is the ONLY viable solution to safegard a file.
> A
> : > single password with 'xor' encryption on a file is as explained,
> useless.
> : >
> : > Cheers,
> :|||> what is necessary to do for encrypt data?
>
Checkout www.database-encryption.com
www.sql-shield.com|||Hi
You are quite right Ridwan. MSSQL is exceptionally weak when it comes to
this. You have hit the nail right on the head. We are quite astonished
that MS has not taken data security seriously. They could at least have
provided some sort of encryption technique that could have restricted access
to all objects in the database outside of SA or sysadmin. The basic
underlying structure of their SQL engine is at fault here. The SA login is
a disaster as is the total control given to sysadmin. It basically makes
the product quite unusable in a mission critical environment. Nothing more,
nothing less. If you do not turn to third party tools to help you with this
dilemna you are basically stuck. If you take data security seriously you
are snookered. You may have to look for a more serious DBMS. We are
currently looking at third party options but most of them do not lock down
table structures and relationships. Hoping to find something that will lock
down the entire database so that it is NOT accessible on another server by
some individual that has gaily made his/her self system administrator. A
shocking state of affairs.
Cheers
Andre
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
> --
> Best regards,
>
> Ridwan
> --
> PemBukuan.Com
> http://www.as3000.com
>

ms sql server 2000 security too weak ?

It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
PemBukuan.Com
http://www.as3000.com
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...
|||1. using NTFS security still allow to get in, and duplicate the
database, this is not why I mean, but they can copy and open it in
another server without any protection.
2. using data encryption of course will slow down the performance while
we process large amount of data
I am not blaming MS, actually the sql server is quite a good and easy to
maintain database, only we are so curious, why other user data like
excel spreadsheet, word, access can have their own password, and
specially the most important data container (sql server) open like a
mall and welcome in, u just login in as 'sa' and u get everything.
Why not MS add an additional login password as an option, may be that's
much better than let it open.

> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
> b.t.w. there is nearly no protection against harddisk access by a
> technician. You can't blame MS for that. But data encryption by the
> application that uses MSDE is a solution...
|||"RW" <goldbase@.centrin.net.id> wrote in message
news:407AB799.4F6F@.centrin.net.id...
> 1. using NTFS security still allow to get in, and duplicate the
> database, this is not why I mean, but they can copy and open it in
> another server without any protection.
> 2. using data encryption of course will slow down the performance while
> we process large amount of data
see below...

> I am not blaming MS, actually the sql server is quite a good and easy to
> maintain database, only we are so curious, why other user data like
> excel spreadsheet, word, access can have their own password, and
> specially the most important data container (sql server) open like a
> mall and welcome in, u just login in as 'sa' and u get everything.
> Why not MS add an additional login password as an option, may be that's
> much better than let it open.
Applying a single password is really a nope-operation. for instance, SQL
stored procs can be encrypted, but they can be decripted using 'tools' that
are available on the net.
So that's why the 'slow' operation, that is a 3 key-algorithm
(public/private/session) is the ONLY viable solution to safegard a file. A
single password with 'xor' encryption on a file is as explained, useless.
Cheers,
|||hi
what is necessary to do for encrypt data?
atte,
Hernn Castelo
UTN Buenos Aires
.. . . . . . . . . . . . . . . . . . . . . . . . . .
"Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en el mensaje
news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...
|||> "Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en
el mensaje
> news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:4079FBD2.559B@.centrin.net.id...
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
"Hernn Castelo" <hhh@.hotmail.com> wrote in message
news:%23KshfkMIEHA.3476@.TK2MSFTNGP11.phx.gbl...
> hi
> what is necessary to do for encrypt data?
> --
> atte,
> Hernn Castelo
> UTN Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . . .
..
Your application can encrypt data. If you have .NET you can use Rijnhaeve
(If I spell correctly) and such. .NET samples show how to do it.
With C++ (7.0 and higher) there are encryption templates as well.
|||You didn't get my question, what I mean is if your database which you
have protect with the algorithm and re-install by somebody in their
server, then all your data will be seen and access using their 'sa'
login, so where's the protection ?
Egbert Nierop (MVP for IIS) wrote:
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407AB799.4F6F@.centrin.net.id...
> see below...
>
> Applying a single password is really a nope-operation. for instance, SQL
> stored procs can be encrypted, but they can be decripted using 'tools' that
> are available on the net.
> So that's why the 'slow' operation, that is a 3 key-algorithm
> (public/private/session) is the ONLY viable solution to safegard a file. A
> single password with 'xor' encryption on a file is as explained, useless.
> Cheers,
|||If the user is an administrator of the SQL Server, then they can steal your
MDF files. But then, they can do anything anyway.
If the user is an administrator of the Windows machine that SQL Server is
on, then they can steal everything on the server anyway.
Normal users can not do this.
So, you need to trust your administrators.
Anyway, even if there was a "separate" password, how would your applications
access the database? They would need the password, which means it has to be
stored somewhere, which means the administrator could steal it from there
(eg from the client application, or by monitoring the traffic that goes into
SQL Server).
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"RW" <goldbase@.centrin.net.id> wrote in message
news:407B4E73.682C@.centrin.net.id...
: You didn't get my question, what I mean is if your database which you
: have protect with the algorithm and re-install by somebody in their
: server, then all your data will be seen and access using their 'sa'
: login, so where's the protection ?
:
:
:
: Egbert Nierop (MVP for IIS) wrote:
: >
: > "RW" <goldbase@.centrin.net.id> wrote in message
: > news:407AB799.4F6F@.centrin.net.id...
: > > 1. using NTFS security still allow to get in, and duplicate the
: > > database, this is not why I mean, but they can copy and open it in
: > > another server without any protection.
: > >
: > > 2. using data encryption of course will slow down the performance
while
: > > we process large amount of data
: >
: > see below...
: >
: > > I am not blaming MS, actually the sql server is quite a good and easy
to
: > > maintain database, only we are so curious, why other user data like
: > > excel spreadsheet, word, access can have their own password, and
: > > specially the most important data container (sql server) open like a
: > > mall and welcome in, u just login in as 'sa' and u get everything.
: > >
: > > Why not MS add an additional login password as an option, may be
that's
: > > much better than let it open.
: >
: > Applying a single password is really a nope-operation. for instance, SQL
: > stored procs can be encrypted, but they can be decripted using 'tools'
that
: > are available on the net.
: > So that's why the 'slow' operation, that is a 3 key-algorithm
: > (public/private/session) is the ONLY viable solution to safegard a file.
A
: > single password with 'xor' encryption on a file is as explained,
useless.
: >
: > Cheers,
:
|||Sometimes trusting people too full is risky to the company, it should be
a double checking procedure and control by two authorized person.
About the monitoring data traffic is not very easy do that if the
application using a native database driver, except ODBC.
My suggestion is when attaching the MDF files will require the original
serial number of ms.sql server 2000 where it was created, I think at
least this is another way to protect the MDF files, even somebody or the
kick out administrator copy it, then it's useless, they should know the
serial number to access the MDF.
What do you think ?
brgs,
Ridwan
Ken Schaefer wrote:
> If the user is an administrator of the SQL Server, then they can steal your
> MDF files. But then, they can do anything anyway.
> If the user is an administrator of the Windows machine that SQL Server is
> on, then they can steal everything on the server anyway.
> Normal users can not do this.
> So, you need to trust your administrators.
> Anyway, even if there was a "separate" password, how would your applications
> access the database? They would need the password, which means it has to be
> stored somewhere, which means the administrator could steal it from there
> (eg from the client application, or by monitoring the traffic that goes into
> SQL Server).
> Cheers
> Ken
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407B4E73.682C@.centrin.net.id...
> : You didn't get my question, what I mean is if your database which you
> : have protect with the algorithm and re-install by somebody in their
> : server, then all your data will be seen and access using their 'sa'
> : login, so where's the protection ?
> :
> :
> :
> : Egbert Nierop (MVP for IIS) wrote:
> : >
> : > "RW" <goldbase@.centrin.net.id> wrote in message
> : > news:407AB799.4F6F@.centrin.net.id...
> : > > 1. using NTFS security still allow to get in, and duplicate the
> : > > database, this is not why I mean, but they can copy and open it in
> : > > another server without any protection.
> : > >
> : > > 2. using data encryption of course will slow down the performance
> while
> : > > we process large amount of data
> : >
> : > see below...
> : >
> : > > I am not blaming MS, actually the sql server is quite a good and easy
> to
> : > > maintain database, only we are so curious, why other user data like
> : > > excel spreadsheet, word, access can have their own password, and
> : > > specially the most important data container (sql server) open like a
> : > > mall and welcome in, u just login in as 'sa' and u get everything.
> : > >
> : > > Why not MS add an additional login password as an option, may be
> that's
> : > > much better than let it open.
> : >
> : > Applying a single password is really a nope-operation. for instance, SQL
> : > stored procs can be encrypted, but they can be decripted using 'tools'
> that
> : > are available on the net.
> : > So that's why the 'slow' operation, that is a 3 key-algorithm
> : > (public/private/session) is the ONLY viable solution to safegard a file.
> A
> : > single password with 'xor' encryption on a file is as explained,
> useless.
> : >
> : > Cheers,
> :
|||> what is necessary to do for encrypt data?
>
Checkout www.database-encryption.com
www.sql-shield.com
sql

MS SQL Record Limit

Quick question, is there a record limit in MSSQL assuming that we don't use a identity key. I am going to be using a table to sava mail server logs. It will create about 5000 records a minute. Also are there any perfomrance issues once you reach a certain numberof records, assuiming i am indexing one of the columns.limited by available storage

[Books Online] Maximum Capacity Specifications

look for rows per table

or LINK (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_ts_8dbn.asp)

now 5000 rows a minute for how long??|||drop any index before inserting data.
when transaction complished,recreate index.|||Also plan to archive the data in order to manage the database efficiently without any issues. say archive the data after a week or month or so.

This way you can ease the administration of the database on the terms of performance etc.

Refer to http://www.sql-server-performance.com for tips and tricks on performance issues.|||Thanks for all your help, I am going to do some testing and see what happens... the best way to learn is to do.

MS SQL query, whats the default order the rows returned are sorted by?

i have a table and a column called req_id, i have it set as the primary key.. so if i just do SELECT * FROM table, shouldnt the rows returned be sorted by the order that the rows were inserted?

this database was improted from an access database.. when i did that in access it would return the rows in sorted order by the order the row was inserted.. but now in MS SQL, its not sorted in that order.. i can't really tell what type of order it's inIf you want an order, specify the order with the ORDER BY clause. If you are willing to take whatever order the optimizer decides on, omit the ORDER BY clause.

-PatP|||hmm this is weird.. in the access database if i select it, they're returned in the order the rows were inserted.. but after importing that database into ms sql, and selecting that table, the order isn't the same row i got when i ran the query in the access db|||Jet, the default database engine used by MS-Access is rather "simple-minded" when it comes to query optimization. MS-SQL has a much more powerful optimizer, which is a two-edged sword... The MS-SQL optimizer is able to easily process queries that Jet would never complete, but it does that processing in a very different way. As an interesting side effect, it also means that unless you specify an order in your query, there is no guarantee that running the exact same query on the same box will ever return the rows in the same order, even though it often will return them in a consistant order.

-PatP|||Ahhh ok i see what you're saying.

In my query, i had a left join statement in there.. i took that out and used a subquery instead of the join and it returns the rows fine now in the order they were inserted. Looks like the join caused the problem.|||No, the JOIN did not cause the problem. The absence of an ORDER BY statement caused the problem.|||The problem is actually a lot simpler than "the join caused the problem". If you want an order, specify it with the ORDER BY clause. If you don't care about an order and are willing to accept the order determined by the optimizer at the moment, omit the ORDER BY clause.

-PatP

MS SQL 2005 identity lost new database

Hello

I am creating a TABLE

CREATE TABLE [dbo].[TbTest](
[id_TbTest] [int] IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED ,
[Title] [varchar](100) NULL,
) ON [PRIMARY]

when looking at the Column Properties in MS Server Management Studio I get :
Identity Specification = Yes
(Is Identity) = Yes
Increment = 1
Seed = 1

now if I want to make a copy of that database, importing datas and tables

I get :
Identity Specification = No
(Is Identity) = No

How can I avoid this problem ? my application is not working anymore

ALTER TABLE [dbo].[TbTest] WITH NOCHECK ADD
CONSTRAINT [PK_TbTest] PRIMARY KEY CLUSTERED
(
[id_TbTest]
) ON [PRIMARY]

is not solving that problem

thank youit sounds like you copied your data using SSIS or DTS or whatever you want to call it. This will copy your data but not your schema. You likely lost all of your indexes and constraints as well. What you want to do if you want to copy all of your data and your schema, is to take a backup of the database you want to copy and restore that database to a new location. If it is a new server, you will have to remap you logins as well.|||With SQL Server 2000 Enterprise Manager you could quickly and easily copy both data and schema between servers. With 2005, you can't. This is Microsoft's idea of progress...

A work-around is to generate a script for you schema and execute it on the target server, and then you SSIS to transfer just the data.|||thank you

what is the code line for ALTER COLUMN to create IDENTITY (1,1)
I must do it now with code ?|||there is not one.

I am a little concerned from what you said in first and last post that you are going to mess up all of your primary key and foreign key relationships.

however if you must you need to create a new table and in your create table statement you must define an identity column. copy the data from your current table to the new one. drop the old table, and rename the new one.|||in that way maybe ?:

ALTER TABLE [dbo].[TbTest] ADD
[id1_TbTest] [int] IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED;
ALTER TABLE [dbo].[TbTest] DROP COLUMN [id_TbTest];
EXEC sp_rename '[TbTest].[id1_TbTest]', 'id_TbTest', 'COLUMN';

thank you