hflsales:
If I use VARCHAR field type, how do I define it to be 28k?
Probably a typo, but I did say '128k'.
As to how to define the size, this will become obvious when you make the change.
Having said that though...
hflsales:
I have never had to edit the database before & wouldn't want to screw anything up.
That's why you should always make a backup BEFORE making ANY changes.
As long as you have a backup it really doesn't matter if you screw up or not. Just restore and try again, being careful to avoid the same mistake(s).
hflsales:
There are a few graphics embedded in the html
Oh. No wonder you are having a problem.
Scrap my previous suggestion, 128k isn't going to be enough.
It need to be large enough to hold the largest amount of data to be stored, but not so large that it wastes resources. You are the only person in a position to determine what is going to be most suitable.. the 16mb MEDIUMTEXT will probably do, but if possible I'd be aiming for half that, or less.
ALSO, VERY IMPORTANT.
You should NOT be storing graphics in a TEXT type field. Graphics files contain binary data and even if they do store properly at the moment (which is a little bit of a surprise), sooner or later something is going to access this data and say 'This isn't right' and will attempt to 'fix' things for you (generally corrupting the data in the process).
If you MUST store graphics in this table it needs to be defined as a type 'BINARY' or 'BLOB'. However, be warned, this may have a negative impact on anything reading this table that is expecting 'pure text'.
One other warning. Changing the datatype on a database with existing records has a high risk of corrupting or deleting data. Rather than make the change on a 'live' database table it is prudent to EXPORT the data first, delete the record. Create the new record type, then IMPORT the data. This process is actually quicker to do than this paragraph has taken to write.
My final word of advise, is that I really don't like what you are doing here. The categories_description field really isn't designed for the purpose you are using it for. It may function perfectly, but my gut is still telling me that you are asking for some kind of unforeseen problem somewhere down the track. If it does cause a problem, down the track it could be a very difficult one to diagnose, because no one is ever going to suspect you've made this change, therefore it won't be factored in when it comes to fault finding... and even if you did mention it, I doubt that anyone here will make the same changes in order to replicate the problem (and that is always the 1st step in problem diagnosis).
Other than these warnings, I wish you well in whatever it is you are trying to achieve. :)
Cheers
Rod
