String lengths in the SQL backend

[Graham Leggett]

Phil Longstaff wrote:

> I'd have to look back, but I think Derek's reply was the only one.  I'd like 
> to open the topic again, because of Rolf's problem.  Can anyone think of a 
> reason that account code size limit cannot be reduced to a smaller value (e.g. 
> 32)?   Will anyone ever enter an account code longer than that?

No matter what you do, any limit that you set will always eventually be 
too small for somebody.

Ideally gnucash should not impose any limit at all - it should be up to 
the entity that creates the database to decide how wide the columns 
should be.

Doing it this way means that database column sizes become the user's 
problem. If the user needs a wider column, the user can make the column 
wider.

If the user chooses a database that supports varchars of "large" size 
efficiently (like postgres), then gnucash should step out the way and 
not impose a limit at all.

In terms of the UI, if gnucash could query the database and say "how 
wide is this column?" and then use that to limit the widths, again it 
means that widths are the user's problem.

Regards,
Graham
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20081112/a83a4f10/attachment.bin