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
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
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
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
Phil Longstaff wrote:
> Derek Atkins wrote:
>
>> Mark Johnson <[EMAIL PROTECTED]> writes:
>>
>>
>>
>>> Mark Johnson wrote:
>>>
>>>
This appears to be separate from the SERIAL problem of libgda's
PostgreSQL provider as PostgreSQL has the highest number of splits.
Derek Atkins wrote:
> Mark Johnson <[EMAIL PROTECTED]> writes:
>
>
>> Mark Johnson wrote:
>>
>>> This appears to be separate from the SERIAL problem of libgda's
>>> PostgreSQL provider as PostgreSQL has the highest number of splits.
>>> (Most complete? Are there duplicates?)
>>>
>>>
>>>
Mark Johnson <[EMAIL PROTECTED]> writes:
> Mark Johnson wrote:
>> This appears to be separate from the SERIAL problem of libgda's
>> PostgreSQL provider as PostgreSQL has the highest number of splits.
>> (Most complete? Are there duplicates?)
>>
>>
>>
> Oops, no it doesn't have the highest
Mark Johnson wrote:
> This appears to be separate from the SERIAL problem of libgda's
> PostgreSQL provider as PostgreSQL has the highest number of splits.
> (Most complete? Are there duplicates?)
>
>
>
Oops, no it doesn't have the highest number of splits. It is three less
than MySql. Na
Configuration:
libgda 3.1.2
gnucash-gda SVN16943
PostgreSQL 8.2.6
MySql 5.0.51
Sqlite 3.3.7
Today, I deleted all the gnucash databases (Well, I just started a new
file for SQLite:-). I made three copies of my current gnucash XML data,
and loaded them into three instances of gnucash SVN (running
14 matches
Mail list logo
