The different databases define and handle VARCHAR types differently.
MySQL documentation states:
"Values in VARCHAR columns are variable-length strings. The length can be
specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3
and later versions."
So, the valid lengths fo
Hi,
By any chance are you running "make -j 2" (or make -j with any
number > 1)? I only ask because it's possible that there's a
race condition and it's trying to build the second library
before the first.
-derek
Quoting Martin Meyer <[EMAIL PROTECTED]>:
> Hi all!
>
> I'm working on a Gentoo b
Hi all!
I'm working on a Gentoo box and I'm having issues getting gnucash
2.2.3 to build. The arch is amd64 (i.e. x86_64), and the processor is
a core 2 quad. I spoke with jsled on IRC for a while and I seem to
have stumped him on this issue. You can find the IRC log here:
http://lists.gnucash.or
Keith Bellairs wrote:
I think that depends on the DB. Using VARCHAR at least gives the engine
a chance to optimize storage. CHAR is good for truly fixed length strings.
This is true, I mixed up the varchar with the char. Adding a limit to
varchar is entirely arbitrary though, if the varchar c
I think that depends on the DB. Using VARCHAR at least gives the engine a
chance to optimize storage. CHAR is good for truly fixed length strings.
On Feb 18, 2008 3:56 PM, Graham Leggett <[EMAIL PROTECTED]> wrote:
> Phil Longstaff wrote:
>
> > Well, as I originally said, I can use a TEXT type whi
Phil Longstaff wrote:
Well, as I originally said, I can use a TEXT type which allows up to 64K
byte strings. Although not unlimited, I assume this is long enough for
everyone's purposes. MySQL stores them as 2byte length + chars. I will
need to check that that libgda has some good method of
Graham Leggett wrote:
> Keith Bellairs wrote:
>
>> Speaking as a user and not someone busting his butt on this, I hate
>> the idea of "unlimited" everything when we go to a DB. Most of our
>> databases have a mechanism (BLOB/CLOB) to store really big things,
>> usually at the cost of indexing or
Keith Bellairs wrote:
Speaking as a user and not someone busting his butt on this, I hate the
idea of "unlimited" everything when we go to a DB. Most of our databases
have a mechanism (BLOB/CLOB) to store really big things, usually at the
cost of indexing or searching (other than with special
Speaking as a user and not someone busting his butt on this, I hate the idea
of "unlimited" everything when we go to a DB. Most of our databases have a
mechanism (BLOB/CLOB) to store really big things, usually at the cost of
indexing or searching (other than with special hacks -- Oracle Text, for
e
On Feb 11, 2008, at 9:09 PM, Mark Johnson wrote:
I'd be interested in any benchmarks you have. Re SQL statement
length: the mysql document says there is a 16MB limit and I didn't
see
any limit in the sqlite documentation. Is there a way of doing
something like:
SELECT DISTINCT tx_guid FRO
Thilo Pfennig wrote:
Maybe this is a misunderstanding but what I mean is that if I make an
entry into the account "bank" I think this should still be visible,
because only if it wont there would be an error. I think oen should
distinct the real bank account and the bank account in GnuCash. Sure
my two cents
I think it would be wise to collect a precise definition of the formal
requirements before making any design decisions.
ABSOLUTELY -- determining requirements is the first step in design.
How about collecting translations of relevant sections of the actual laws in
the wiki, to
Mark Johnson wrote:
Do we really want "unlimited"? I've alluded to this question in the
past, but I don't know if there's been a definitive answer.
Speaking for myself, I really want unlimited.
As the accounting system is most often the system data is sent to,
rather than originated from, i
13 matches
Mail list logo
