| Author |
Topic |
|
cidr2
Starting Member
28 Posts |
 Posted - 2008-12-03 : 09:43:33
|
| Hi there,quick question, is there any risks changing a Varchar(30) to a Varchar(50)? the db is the backend of a third party time recording tool and the last thing I want to do is break it just because the organisation needs longer names.Thanks in advance for any help. |
|
|
jholovacs
Posting Yak Master
163 Posts |
Posted - 2008-12-03 : 09:48:34
|
| I'd say the biggest risk is total failure. If your third party app is expecting a VARCHAR(30) and you try to shoehorn a 35-character string into it, depending on the nature of your third party system, you could get truncated data, or it could just crash. Or it could do nothing and be perfectly fine with it.In short, it sounds like something you should not do unless you absolutely have to... and even then, I'd recommend a firm CYA policy in case everything breaks.___________________________Geek At Large |
 |
|
|
sodeep
Master Smack Fu Yak Hacker
7174 Posts |
Posted - 2008-12-03 : 09:52:05
|
| You should be fine.I recommend you do in offline hours if its production. |
|
|
|
jholovacs
Posting Yak Master
163 Posts |
Posted - 2008-12-03 : 10:09:17
|
| I have to strongly disagree with sodeep here. Not knowing anything about this third-party app, the best you can hope for is implicit truncation. You're implying that you will be injecting larger strings than your third-party application is expecting, which can easily result in a buffer overrun, or malformed data in the app.There are indeed serious risks, and it should be tested thoroughly before going anywhere near production.___________________________Geek At Large |
|
|
|
mcrowley
Aged Yak Warrior
771 Posts |
Posted - 2008-12-03 : 10:45:52
|
| Changing the table may not work. Some of my own adventures have seen stored procedures with variables the old size truncating the data, and parameter objects in VB/ASP being set to the old length, and again truncating values. The only other risk is the 900 byte limit on index key size, but adding 20 bytes should not run you afoul of that limit, unless they have some VERY interesting indexes.After all the disclaimers, the best thing to do is use a test system to try out the change to see if it works for you. Don't touch production, unless you know it is going to do exactly what you expect. Also, play around in a database of your own to make sure you can back out such a change if it goes horribly wrong. Even if it requires a database restore. |
|
|
|
sodeep
Master Smack Fu Yak Hacker
7174 Posts |
Posted - 2008-12-03 : 10:54:01
|
quote:
Originally posted by jholovacs
I have to strongly disagree with sodeep here. Not knowing anything about this third-party app, the best you can hope for is implicit truncation. You're implying that you will be injecting larger strings than your third-party application is expecting, which can easily result in a buffer overrun, or malformed data in the app.There are indeed serious risks, and it should be tested thoroughly before going anywhere near production.___________________________Geek At Large
I said because Op is going from varchar(30) to varchar(50).I have also considered the fact that Database is backed up to point of change so it can be rolled back anything happens. Please test with it before applying to production . |
|
|
|
darkdusky
Aged Yak Warrior
591 Posts |
Posted - 2008-12-03 : 11:32:29
|
| If you increase the column size in the table there is no risk to the data currently held in the database.If the 3rd party app has set variable lengths in stored procedures or applications which match the smaller sizes there should be no errors or truncation as long as the actual data is still no bigger than the original size.So it is fairly safe to increase size of column but NOT insert the longer names. Test at this stage - if no problems add a few test longer names to see if you get errors or truncations. If still no errors probably safe to proceed (but with backups etc) |
|
|
|
jholovacs
Posting Yak Master
163 Posts |
Posted - 2008-12-03 : 12:11:05
|
| I'll agree with darkdusky in that everything he said is accurate. BUT... why would you increase the size of a column if the ultimate goal is not to use the extra size? I believe the implication is clear that cidr2 has every intention of putting in varchar values that exceed 30 bytes in length, and there is lots of opportunity for bad things to happen at that point.___________________________Geek At Large |
|
|
|
cidr2
Starting Member
28 Posts |
Posted - 2008-12-04 : 10:34:28
|
| Thanks for the response folks,It wouldn't be a problem to increase size if I knew what was going on in the third party app, since I don't, I'm not going to take any further action and you've all helped me come to the right conclusion.Perhaps I'll try it in a test enviroment one day but until then, users will have to live with abbreviated names ;)Cheers |
|
|
|
tfountain
Constraint Violating Yak Guru
491 Posts |
Posted - 2008-12-04 : 11:09:29
|
| Do what we do with our third party software components... submit an enhancement request to the vendor and wait for it to be rolled out in an update.Just as a matter of opinion, if you have no control over the application you really should not mess with the data structures it uses. The only extent you should tamper with 3rd party software databases are administration level items (where data files are located, etc). But tinkering with the data and schemas - tsk tsk :). |
|
|
|
darkdusky
Aged Yak Warrior
591 Posts |
Posted - 2008-12-04 : 11:35:09
|
quote:
Originally posted by jholovacs
I'll agree with darkdusky in that everything he said is accurate. BUT... why would you increase the size of a column if the ultimate goal is not to use the extra size? I believe the implication is clear that cidr2 has every intention of putting in varchar values that exceed 30 bytes in length, and there is lots of opportunity for bad things to happen at that point.___________________________Geek At Large
The last stage of my proposed changes was to add the longer strings - but in a small steps which can be back-tracked with minimum risk of disruption if any errors arose. |
|
|
|
|
Risks increasing Datatype size?