On 2017-10-28 09:53, Ed Leafe wrote:
On Oct 28, 2017, at 7:58 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I don't do that but I thought using varchar(n) fields were supposed to be space-efficient in a sense that it just used a extra 1 or 2 bytes up front at the head of the record to identify the true length? It's not really allocating the space like a CHAR(n) field would...right?
Yes, it only uses the space needed for the value. Again, the primary concern isn't disk storage space, but indexing. If you have *any* variable-width columns in a table, the table no longer has fixed record length, so you lose the fixed offset for searching. The moral of the story is if you use VARCHAR anywhere in a table, you might as well make all string columns VARCHAR.
Hi Ed,
Yep...I recall hearing that years ago, too (regarding any varchars make the whole row a varchar in string fields, basically).
Would you ever use fixed CHARs with a non-VFP backend for that fixed offset advantage, again with the idea that storage is cheap/available?
tia, --Mike