lvarchar

Hi, could anybody advise me about the datatype lvarchar? Different sources give me different information about its size, one source tells me 2 K, another says its 4 GB!. Is there a reason why this type can not be selected when connected via dbaccess while there is no problem or warning when used inside a create table statement? (IDS 9.3 on Linux). Regards, Michael

michael wimmer wrote: > could anybody advise me about the datatype lvarchar? Different sources give > me different information about its size, one source tells me 2 K, another > says its 4 GB!. > > Is there a reason why this type can not be selected when connected via > dbaccess while there is no problem or warning when used inside a create > table statement? (IDS 9.3 on Linux). LVARCHAR is schizophrenic - both statements are accurate (and hence inaccurate too). And somewhat version dependent. Prior to 9.40, LVARCHAR used to store data in a table was limited to 2 KB (and you could not say how much space you might use). With 9.40, the limit is just short of 32 KB (and you get to specify the maximum length - we'll assume 2 KB if you don't). However, LVARCHAR can also be used to transfer data back and forth between database and client, and in datablades, and in that context, the type support LVARCHAR has a 32-bit unsigned size field, leading to the 4 GB limitation. Since you're using Linux and 9.30, you are stuck with 2 KB in a table, but you still have 4 GB for transport purposes. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

"Jonathan Leffler" <jleffler@earthlink.net> wrote > LVARCHAR is schizophrenic - both statements are accurate (and hence > inaccurate too). And somewhat version dependent. > > Prior to 9.40, LVARCHAR used to store data in a table was limited to 2 > KB (and you could not say how much space you might use). With 9.40, > the limit is just short of 32 KB (and you get to specify the maximum > length - we'll assume 2 KB if you don't). > > However, LVARCHAR can also be used to transfer data back and forth > between database and client, and in datablades, and in that context, > the type support LVARCHAR has a 32-bit unsigned size field, leading to > the 4 GB limitation. In version 9.21.UC4: lvarchar variable in a stored procedure suffers from the same limitation as table size, that is 2K only. We found out the hard way when we created a string dynamically and it eventually went > 2K. The lvarchar variable which was suppose to recv that string spew out error. (forgot the error #) For us it was an annoying limitation because we were using that lvarchar variable to transport back a row data (we are sending all columns as a single lvarchar string, separated by a column delimiter) to the client.