I'm not 100% sure, but SQL server 6 or 7 (I think, from memory) has a max record size of 8000 bytes or something weird. We had a couple of varchar 4000 fields and all the normal fields on top of that (PK, FKs, etc etc). It was fine till it started truncating info. Much research later and it turned out that the max record length was being exceeded. Hence the text field type and its data pointer goodness... One confirmation here: http://west-wind.com/weblog/posts/207.aspx
If your wddx access does not need to be lightning fast, another option is to store it on the HDD and just store a reference to the file in your database table. HTH Aaron Jim Davis wrote: >>-----Original Message----- >>From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] >>Sent: Sunday, October 16, 2005 12:06 AM >>To: CF-Talk >>Subject: RE: zipping and unzipping a string >> >> >> >>>From: John Blayter [mailto:[EMAIL PROTECTED] >>>I am looking for a way to zip and unzip a string without >>>going to the hard drive to perform I/O operations. I have >>>started hacking away at some code but I don't know enough >>>Java to get it working. >>> I have a WDDX packet that can be between 9 - 14K that we >>>want to store in a SQL server database. The database guy has >>>hatred towards using a text data type and has challenged us >>>to find a way to fit a 14K wddx packet into a >>>varchar(8000) field. Any help would be greatly appreciated. >>> Thanks, >>> >>> >>I would tell your DBA that large data types exist for a reason... large >>data! What is his reasoning for not wanting the text data type used? What >>is >>the purpose of the field, will it be searched? Indexed? Is the DBA >>familiar >>with "Text In Row" (alleviates the double I/O or text retrieval)... etc... >> >> > >Yeah... I gotta agree. You shouldn't change your data because of a personal >"hatred" towards a perfectly usable feature. Does he have actual reasons? >Anything that will offset the development time needed (and they completely >lack of flexibility assumed) from hacking large data to fit in a smaller >field? > >Look at the data. Use the data type most appropriate to the data. That's >really DB 101 there. > >If you have problems after that optimize, consider kludges, etc. But not to >do the logical thing because of a unsubstantiated personal opinion is just >plain silly. > >Jim Davis > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:221148 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
