Welcome to WebmasterWorld Guest from 54.146.211.105

Forum Moderators: open

Message Too Old, No Replies

Changing Field Size in SQL Server

on a Live database... I know!

     
1:47 pm on Aug 30, 2005 (gmt 0)

Junior Member

10+ Year Member

joined:July 14, 2003
posts:130
votes: 0


Hello all,

A quick question please - does changing field size of a varchar field from 2000 to 3000 have any detrimental effects to the data, when working with SQL Server?

Im using Enterprise Manager to work with the database. In MS Access I can change up with no problems and lose data if changing down to less than the size of the data and also get a warning when im decreasing.

Can anyone whose done this on SQL Server give me some pointers. Oh and its a LIVE database with some fairly important data in it :-) (I know! - im just having to support it)

Cheers

2:34 pm on Aug 30, 2005 (gmt 0)

Junior Member

10+ Year Member

joined:July 14, 2003
posts:130
votes: 0


Hello all,

Decided to risk it... and it turned out that you can't have much more than 8000 bytes in a single SQL Server row anyway!

So it will require a proper redevelopment rather than a quick fix, which if it comes back to me will allow me to set up a testing environment.

In case anyone ever wants to know a solution is to use a separate table with just a primary key in it and link back the larger fields to the original table/s.

Cheers

2:41 pm on Aug 30, 2005 (gmt 0)

Full Member

10+ Year Member

joined:Feb 5, 2002
posts:333
votes: 0


Hi Mr Brutal.

I think you just highlighted the case for having an off-line development server. I have this kind of set up and i can mess with my test database as much as I like before applying changes to the live web server.

2:47 pm on Aug 30, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Jan 31, 2005
posts:1651
votes: 0


You should have no problem in increasing a Varchar column's lenght.
However keep in mind that the total row size should not exced 8KB.
3:36 pm on Sept 5, 2005 (gmt 0)

Preferred Member

10+ Year Member

joined:Feb 16, 2005
posts:456
votes: 0


Also note that during the "alter table" command there will be an exclusive lock on the table so all other processes wishing to access this table will be temporarily blocked.

arran.

6:35 pm on Sept 9, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Feb 13, 2005
posts:1077
votes: 0


If you need more space then varchar will allow, use 'ntext' or 'text'
1:14 am on Sept 10, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:June 2, 2003
posts:1184
votes: 0


Mr_Brutal (next time) if you don't have a testing environment you could simply:

- Script out the table and in the script rename it to something new like [tablenameTEST] and then create that new test table.
- Use DTS to copy the LIVE data into the test table.
- Expand the table column to fit your needs
- Run some unit tests at it.

5:03 pm on Sept 10, 2005 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:June 13, 2002
posts:2162
votes: 0


use 'ntext' or 'text'

Bear in mind if you do this you cannot group by text datatypes, so queries and views where you use Max(), Sum() or Count() will probably have to be re-written.
8:33 am on Sept 12, 2005 (gmt 0)

Junior Member

10+ Year Member

joined:July 14, 2003
posts:130
votes: 0


Hi Easy_Coder,

Thats a good idea - basically just copy the table and then try it. Should have thought of that...

My only concern was that it was Live but im sure copying tables on Live databases is well coded for.

Cheers

3:32 pm on Sept 12, 2005 (gmt 0)

Full Member

10+ Year Member

joined:Sept 24, 2002
posts:214
votes: 0


Mr_Brutal.

I have also had a similar problem to this. rather than copy the whole table I have created a new table with a varchar coloumn of 2000 added some data, then increased it to 3000 just to test the concept and it has worked, might save a bit of time.