On 02-07-13 20:53, Christian Stimming wrote:
Dear Geert or John or whoever knows this,
where does gnucash store the database password for MySQL or PostgreSQL
backend? It stores the database name, host, and username directly in the URI,
which is also visible in the file history. The URI (without
Donald Allen writes:
> Some good news:
>
> Doing this the easy way first, I did a little manual pc sampling. I
> ran gnucash (today's trunk) under gdb, let it get to the point where
> it begins to load my data from postgresql, and periodically ctrl-c'd
> in gdb and copied the interrupted location
On Thu, 2010-02-25 at 09:49 +0100, Christian Stimming wrote:
> Zitat von Phil Longstaff :
> >> http://lists.gnucash.org/pipermail/gnucash-devel/2009-August/026121.html
> >> and
> >> my commit r18675 recently. I didn't apply this to the full source
> >> tree so far
> >> in order not to destroy so
Zitat von Phil Longstaff :
http://lists.gnucash.org/pipermail/gnucash-devel/2009-August/026121.html and
my commit r18675 recently. I didn't apply this to the full source
tree so far
in order not to destroy some people's diffs which are still waiting to be
applied... I think the directory you'r
On Wed, 2010-02-24 at 22:18 +0100, Geert Janssens wrote:
> On Wednesday 24 February 2010, Phil Longstaff wrote:
> > On Wed, 2010-02-24 at 20:50 +0100, Christian Stimming wrote:
> > Christian, could you create such a central file with the options you are
> > using?
> >
> Agreed on the idea of an op
On Wednesday 24 February 2010, Phil Longstaff wrote:
> On Wed, 2010-02-24 at 20:50 +0100, Christian Stimming wrote:
> > > So I applied the same treatment to load_splits_for_tx_list,
> > > substituting g_list_prepend for g_list_append inside the
> > > split-fetching loop and reversing the list on co
On Wed, 2010-02-24 at 20:50 +0100, Christian Stimming wrote:
> > So I applied the same treatment to load_splits_for_tx_list,
> > substituting g_list_prepend for g_list_append inside the
> > split-fetching loop and reversing the list on completion of the loop.
> > I rebuilt and tried again and now m
On Wed, 2010-02-24 at 14:37 -0500, Donald Allen wrote:
Great! I'll apply the patch. There are probable other places which
would benefit from this. There might also be places where the order is
unimportant so that the list doesn't need to be reversed.
> BTW, I found the indentation/formatting o
> So I applied the same treatment to load_splits_for_tx_list,
> substituting g_list_prepend for g_list_append inside the
> split-fetching loop and reversing the list on completion of the loop.
> I rebuilt and tried again and now my data loads in about 9 seconds,
> approximately the same as the xml
Some good news:
Doing this the easy way first, I did a little manual pc sampling. I
ran gnucash (today's trunk) under gdb, let it get to the point where
it begins to load my data from postgresql, and periodically ctrl-c'd
in gdb and copied the interrupted location and a backtrace to an emacs
buffe
On Wed, Feb 24, 2010 at 10:32 AM, Phil Longstaff wrote:
> On Wed, 2010-02-24 at 09:59 -0500, Derek Atkins wrote:
>> Donald Allen writes:
>>
>> >> I think true measurements will be the only way to find out what causes
>> >> delays
>> >> where.
>> >
>> > Of course. I spent a big chunk of my career
On Wed, 2010-02-24 at 09:59 -0500, Derek Atkins wrote:
> Donald Allen writes:
>
> >> I think true measurements will be the only way to find out what causes
> >> delays
> >> where.
> >
> > Of course. I spent a big chunk of my career doing performance analysis
> > on various bits of complicated so
Donald Allen writes:
>> I think true measurements will be the only way to find out what causes delays
>> where.
>
> Of course. I spent a big chunk of my career doing performance analysis
> on various bits of complicated software and learned very young (the
> hard way) that if you think you know h
On Tue, Feb 23, 2010 at 11:40 AM, Geert Janssens
wrote:
> On Tuesday 23 February 2010, Donald Allen wrote:
>> On Tue, Feb 23, 2010 at 9:15 AM, Geert Janssens
>> > Your assumptions on how things work are correct.
>> >
>> > And I noticed this performance decrease as well.
>> >
>> > There is one diff
On Tuesday 23 February 2010, Donald Allen wrote:
> On Tue, Feb 23, 2010 at 9:15 AM, Geert Janssens
> > Your assumptions on how things work are correct.
> >
> > And I noticed this performance decrease as well.
> >
> > There is one difference between the xml and the sql backends that may
> > influenc
On Tue, Feb 23, 2010 at 9:15 AM, Geert Janssens
wrote:
> On Tuesday 23 February 2010, Donald Allen wrote:
>> As I've mentioned in other posts, I have a pretty large gnucash
>> datafile -- more than 20 Mb uncompressed. I've been testing the SQL
>> backend and I'm concerned about the performance, pa
On Tuesday 23 February 2010, Donald Allen wrote:
> As I've mentioned in other posts, I have a pretty large gnucash
> datafile -- more than 20 Mb uncompressed. I've been testing the SQL
> backend and I'm concerned about the performance, particularly startup
> performance.
>
> I've been doing this t
Phil Longstaff wrote:
> The interesting line in your log is:
> * 07:22:41 INFO [init_sql_backend] -1 DBD drivers
> found
>
> which means that there was some problem initializing libdbi.
>
> Your listing above shows that the dbd file are in /usr/local/lib/dbd. My
> packages (ubuntu) put
On February 1, 2009 02:33:24 pm Derek Atkins wrote:
> Phil,
>
> Quoting Phil Longstaff :
> > which means that there was some problem initializing libdbi.
> >
> > Your listing above shows that the dbd file are in /usr/local/lib/dbd. My
> > packages (ubuntu) put them in /usr/lib/dbd, so that is what
Phil,
Quoting Phil Longstaff :
> which means that there was some problem initializing libdbi.
>
> Your listing above shows that the dbd file are in /usr/local/lib/dbd. My
> packages (ubuntu) put them in /usr/lib/dbd, so that is what I made the
> default. I would assume that /usr/lib/dbd doesn't
On February 1, 2009 12:08:40 pm Mark Johnson wrote:
> >>> On January 31, 2009 09:34:32 am Mark Johnson wrote:
> I have built trunk rev 17855 with the wrong configure options. I
> accidentally used the old --enable-gda instead of the correct
> --enable-dbi. The file menu has a Datab
Phil Longstaff wrote:
> On January 31, 2009 11:07:17 pm Mark Johnson wrote:
>
>> Phil Longstaff wrote:
>>
>>> Hmmm... 'configure' does allow any wrong options and does not seem to
>>> flag it. What is *supposed* to happen (and what happens for me) is that
>>> the 'Database Connection' menu
On January 31, 2009 11:07:17 pm Mark Johnson wrote:
> Phil Longstaff wrote:
> > Hmmm... 'configure' does allow any wrong options and does not seem to
> > flag it. What is *supposed* to happen (and what happens for me) is that
> > the 'Database Connection' menu item will be there, but insensitive u
Hmmm... 'configure' does allow any wrong options and does not seem to flag it.
What is *supposed* to happen (and what happens for me) is that the 'Database
Connection' menu item will be there, but insensitive unless '--enable-dbi' is
specified.
Can you send me your config.log and config.h?
On October 29, 2008 10:14:40 am Derek Atkins wrote:
>
> Yeah, it should get fixed.. If the user specifies --enable-dbi then
> it should AC_MSG_ERROR() if configure cannot find it.
It already does. I don't understand how it would compile. For me, configure
aborts if the necessary include file d
Rolf Leggewie <[EMAIL PROTECTED]> writes:
> Rolf Leggewie wrote:
>> Phil Longstaff wrote:
>>> I'm using kubuntu 8.04. I have libdbi0, libdbi0-dev, libdbd-mysql and
>>> libdbd-sqlite3 (among other) packages installed.
>>
>> I'm on Ubuntu as well. I was missing all of the above packages except
>
On Wed, 2008-10-29 at 13:39 +0100, Rolf Leggewie wrote:
> Rolf Leggewie wrote:
> > Phil Longstaff wrote:
> >> I'm using kubuntu 8.04. I have libdbi0, libdbi0-dev, libdbd-mysql and
> >> libdbd-sqlite3 (among other) packages installed.
> >
> > I'm on Ubuntu as well. I was missing all of the above
Rolf Leggewie wrote:
> Phil Longstaff wrote:
>> I'm using kubuntu 8.04. I have libdbi0, libdbi0-dev, libdbd-mysql and
>> libdbd-sqlite3 (among other) packages installed.
>
> I'm on Ubuntu as well. I was missing all of the above packages except
> libdbi0. I have installed them now and will retr
Phil Longstaff wrote:
> I'm using kubuntu 8.04. I have libdbi0, libdbi0-dev, libdbd-mysql and
> libdbd-sqlite3 (among other) packages installed.
I'm on Ubuntu as well. I was missing all of the above packages except
libdbi0. I have installed them now and will retry a compile.
> BTW, when I run
Derek Atkins wrote:
> DBI. When you --enable-dbi what does the config.log say about it
> finding DBI?
I don't understand too much about it, but I don't think it looks good.
$ grep -i dbi config.log
$ ./configure --prefix=/export/gnucash --enable-debug
--enable-doxygen --enable-locale-specif
On Tue, 2008-10-28 at 15:32 +0100, Rolf Leggewie wrote:
> Derek Atkins wrote:
> >> lib/libgnc-backend-sql.so will always be built.
> >
> > Actually, it should only be built if you --enable-sql
>
> I rebuilt r17663 with --enable-sql and the situation is completely
> unchanged. What do I do now?
Rolf Leggewie <[EMAIL PROTECTED]> writes:
> Derek Atkins wrote:
>>> lib/libgnc-backend-sql.so will always be built.
>>
>> Actually, it should only be built if you --enable-sql
>
> I rebuilt r17663 with --enable-sql and the situation is completely
> unchanged. What do I do now? I really want SQ
Phil Longstaff <[EMAIL PROTECTED]> writes:
> On Mon, 2008-10-27 at 15:36 -0400, Derek Atkins wrote:
>
>> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>>
>> >
>> > lib/libgnc-backend-sql.so will always be built.
>>
>> Actually, it should only be built if you --enable-sql
>>
>
>
> When I made the
Derek Atkins wrote:
>> lib/libgnc-backend-sql.so will always be built.
>
> Actually, it should only be built if you --enable-sql
I rebuilt r17663 with --enable-sql and the situation is completely
unchanged. What do I do now? I really want SQL support.
_
On Mon, 2008-10-27 at 15:36 -0400, Derek Atkins wrote:
> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>
> >
> > lib/libgnc-backend-sql.so will always be built.
>
> Actually, it should only be built if you --enable-sql
>
When I made the switch from libgda to libdbi, I actually split the
backend
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> On Mon, 2008-10-27 at 18:39 +0100, Rolf Leggewie wrote:
>
>> Phil Longstaff wrote:
>> > The only think I can think of is that the dbi module isn't being loaded.
>>
>> Phil,
>>
>> thank you for your continued support.
>>
>> So, this just may be a case o
On Mon, 2008-10-27 at 18:39 +0100, Rolf Leggewie wrote:
> Phil Longstaff wrote:
> > The only think I can think of is that the dbi module isn't being loaded.
>
> Phil,
>
> thank you for your continued support.
>
> So, this just may be a case of incorrectly compiling gnucash? I sure
> hope I wa
Phil Longstaff wrote:
> The only think I can think of is that the dbi module isn't being loaded.
Phil,
thank you for your continued support.
So, this just may be a case of incorrectly compiling gnucash? I sure
hope I wasn't wasting everybody's time because of my stupidity.
There is no file li
The only think I can think of is that the dbi module isn't being loaded.
>From your log:
* 12:09:52 DEBUG [enter
qofsession.c:qof_session_load_backend()] list=2, initted=false
>From my log:
* 18:03:14 DEBUG [enter
qofsession.c:qof_session_load_backend()] list=5, initted=false
The in
Phil Longstaff <[EMAIL PROTECTED]> writes:
> Rolf Leggewie wrote:
>> Phil Longstaff wrote:
>>
>>> What is in /tmp/gnucash.trace?
>>>
>>
>> * 23:19:48 WARN
>> /home/rolf/.gnucash/config-1.8.auto:13:15: While evaluating arguments to
>> gnc:lookup-option in expression (gnc:lookup-option g
Phil Longstaff wrote:
> See http://wiki.gnucash.org/wiki/Logging.
Phil, thank you for your continued support.
I hope you can help me decipher http://oss.leggewie.org/wip/gnucash.log
which does contain some sql-related messages now. ~/.gnucash/log.conf
is at http://oss.leggewie.org/wip/log.conf
Rolf Leggewie wrote:
> Phil Longstaff wrote:
>
>> When I tried to connect to a mysql db, I got the same popup,
>>
>
> OK. So it did not work in your case, either?
>
>
>> I assume you have an up-to-date trunk.
>>
>
> Rebuilt today. r17608.
>
> _
Phil Longstaff wrote:
> When I tried to connect to a mysql db, I got the same popup,
OK. So it did not work in your case, either?
> I assume you have an up-to-date trunk.
Rebuilt today. r17608.
___
gnucash-devel mailing list
gnucash-devel@gnucash.o
Rolf Leggewie wrote:
> Phil Longstaff wrote:
>
>> This is all there is? Nothing related to SQL or backend?
>>
>
> Today I have one more line, but I don't think it is what you are looking
> for, either.
>
> * 13:52:01 CRIT gtk_widget_event: assertion
> `WIDGET_REALIZED_FOR_EVENT (widget
Phil Longstaff wrote:
> This is all there is? Nothing related to SQL or backend?
Today I have one more line, but I don't think it is what you are looking
for, either.
* 13:52:01 CRIT gtk_widget_event: assertion
`WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
What do we do now?
_
Rolf Leggewie wrote:
> Phil Longstaff wrote:
>
>> What is in /tmp/gnucash.trace?
>>
>
> * 23:19:48 WARN
> /home/rolf/.gnucash/config-1.8.auto:13:15: While evaluating arguments to
> gnc:lookup-option in expression (gnc:lookup-option gnc:*options-entries*
> "__new_user" ...):
> /home/rol
Phil Longstaff wrote:
> What is in /tmp/gnucash.trace?
* 23:19:48 WARN
/home/rolf/.gnucash/config-1.8.auto:13:15: While evaluating arguments to
gnc:lookup-option in expression (gnc:lookup-option gnc:*options-entries*
"__new_user" ...):
/home/rolf/.gnucash/config-1.8.auto:13:15: Unbound variab
What is in /tmp/gnucash.trace?
Rolf Leggewie wrote:
> Rolf Leggewie wrote:
>
>> The result was an error message "Can't parse the URL
>> /home/rolf/.gnucash/data/mysql:,,$server:gnucash:$user:$pw." What am I
>> doing wrong?
>>
>
> By reading some older messages from Phil to this list, I
Rolf Leggewie wrote:
> The result was an error message "Can't parse the URL
> /home/rolf/.gnucash/data/mysql:,,$server:gnucash:$user:$pw." What am I
> doing wrong?
By reading some older messages from Phil to this list, I found out that
overwriting an existing sqlite3 file with "Save As" might
o be kept in sync
(suggest alternate routine names if you want).
Phil
- Original Message
From: Derek Atkins <[EMAIL PROTECTED]>
To: Phil Longstaff <[EMAIL PROTECTED]>
Cc: GnuCash development list
Sent: Friday, July 11, 2008 9:43:42 PM
Subject: Re: SQL backend and dir
Phil,
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> I've investigated my transaction/split issue further and it appears
> as though the problem is in how qof determines that the books are
> dirty.
>
> There is an alt_dirty_mode flag in qof and the gc engine sets it to
> TRUE. When this flag i
"Albert Lash" <[EMAIL PROTECTED]> writes:
>> That's right; each backend is basically stand-alone. Of course it shares a
>> rough outline with the runtime object model and XML data-model, just by
>> nature.
>
> Hmm, I'm a little confused now. The code referenced earlier had to do
> with GDM, right?
> That's right; each backend is basically stand-alone. Of course it shares a
> rough outline with the runtime object model and XML data-model, just by
> nature.
Hmm, I'm a little confused now. The code referenced earlier had to do
with GDM, right? And GDM was replaced by QOF? Or is it that they t
"Albert Lash" <[EMAIL PROTECTED]> writes:
> Am I correct in my assumption that this code isn't actually used with
> the current, non-SQL, backend?
That's right; each backend is basically stand-alone. Of course it shares a
rough outline with the runtime object model and XML data-model, just by
n
"Albert Lash" <[EMAIL PROTECTED]> writes:
[snip]
> Am I correct in my assumption that this code isn't actually used with
> the current, non-SQL, backend? I did a little reading on the GnuCash
> backend (QOF) and it seemed to me that there was a fair amount of
> abstraction going on.
Correct, thi
Yep, thanks for digging the gnc-transaction-gda.c code up. This is
sort of what I was looking for:
107 static col_cvt_t split_col_table[] =
108 {
109 { "guid",CT_GUID, 0, COL_NNUL|COL_PKEY,NULL,
110 get_guid, set_guid },
111 { "tx_guid",
keith <[EMAIL PROTECTED]> writes:
> I know there was discussion on the list last year of a data model that
> was being tested in pg and mysql. But I haven't seen it yet. As Derek
> says, it appears not to have made it into the branch. (Unless is has
> some other sneaky name.)
It looks like the
The sql script for creating tables has lived at
/src/backend/postgres/table-create.sql
The version in the gda-dev branch was last changed in 2003, so it is
somewhat poisonous.
I know there was discussion on the list last year of a data model that
was being tested in pg and mysql. But I haven't
"Albert Lash" <[EMAIL PROTECTED]> writes:
> Is the data model that is / was used for the SQL backend around anywhere?
Check the email archives. Phil had sent in some designs about
a year ago or so.. But I dont think those designs made it into
the gda-dev branch anywhere.
-derek
--
Dere
Very interesting, that's probably what I'm looking for so I'll try to
dig that up.
On 7/20/07, Hale Boyes, Kevin <[EMAIL PROTECTED]> wrote:
> Albert Lash wrote:
> > Is the data model that is / was used for the SQL backend around
> > anywhere?
>
>
> I don't know the answer to that question but ther
Albert Lash wrote:
> Is the data model that is / was used for the SQL backend around
> anywhere?
I don't know the answer to that question but there was a recent
addition to contrib that has a PostgreSQL schema and a perl
program for loading a gnucash datafile.
K.
This email communication and a
Is the data model that is / was used for the SQL backend around anywhere?
On 7/19/07, Nathan Buchanan <[EMAIL PROTECTED]> wrote:
>
> On 7/19/07, Derek Atkins <[EMAIL PROTECTED]> wrote:
> >
> > keith <[EMAIL PROTECTED]> writes:
> >
> > > There was a thread going last year on the SQL backend. I'd be
On 7/19/07, Derek Atkins <[EMAIL PROTECTED]> wrote:
>
> keith <[EMAIL PROTECTED]> writes:
>
> > There was a thread going last year on the SQL backend. I'd be interested
> > in testing/helping. I'm currently doing a lot of work in (shudder)
> > Oracle, but I can install pg too. I checked out the svn
keith <[EMAIL PROTECTED]> writes:
> There was a thread going last year on the SQL backend. I'd be interested
> in testing/helping. I'm currently doing a lot of work in (shudder)
> Oracle, but I can install pg too. I checked out the svn, but haven't dug
> much further.
It's the 'gda-dev' branch
2006/10/30, Derek Atkins <[EMAIL PROTECTED]>:
> Phil Longstaff <[EMAIL PROTECTED]> writes:
>
> >> Sorry, what I meant was that I didn't understand what you meant by
> >> "small add-on".. I don't know GDA well-enough to know what that means
> >> or how that would work.
> >>
> >> > Phil
> >
> > I ha
Phil Longstaff <[EMAIL PROTECTED]> writes:
>> Sorry, what I meant was that I didn't understand what you meant by
>> "small add-on".. I don't know GDA well-enough to know what that means
>> or how that would work.
>>
>> > Phil
>
> I haven't thought this through entirely, but these are my first
>
On Fri, 2006-10-27 at 12:56 -0400, Derek Atkins wrote:
> > Frequency specs are another example, because a compound fs can have
> fs's
> > as children.
>
> I dont know enough about FS to know whether they are also atomic
> objects like KVPs.
They are, in the composite case.
--
...jsled
http://a
On Sat, 2006-28-10 at 11:46 -0400, Derek Atkins wrote:
> Phil Longstaff <[EMAIL PROTECTED]> writes:
>
> >> > Since the connection string will be db-specific, we may want a db core
> >> > built around libgda (see libgda vs libdbi e-mail) with a small add-on to
> >> > handle the connection string fo
Phil Longstaff <[EMAIL PROTECTED]> writes:
>> > Since the connection string will be db-specific, we may want a db core
>> > built around libgda (see libgda vs libdbi e-mail) with a small add-on to
>> > handle the connection string formatting and how guid's will be handled
>> > (as well as adding d
> I think we absolutely MUST support SQLite, and we SHOULD support
> MySQL and PG. Does someone want to volunteer to find the LCD
> features of those three DBs?
Here it is for SQLLite: http://www.sqlite.org/omitted.html
Main areas that may bite us (i owuld think):
-You can't drop a colum
On Fri, 2006-27-10 at 12:33 -0400, Derek Atkins wrote:
> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>
> >> I still don't understand why you want to do this. What does it buy
> >> us? It seems to add a LOT of complexity on the GnuCash side when
> >> building up SQL queries. Instead of just bein
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> OK. I was just giving an example. A better one which comes to mind is
> with kvp frames. A kvp frame can be a number, string, date, list, or
> subframe. Each element of a list is in itself, a kvp frame, so there's
> a hierarchy here (and Josh menti
Quoting "Jim C. Nasby" <[EMAIL PROTECTED]>:
> On Fri, Oct 27, 2006 at 11:51:50AM -0400, Derek Atkins wrote:
>> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>>
>> > You'd be better off creating a stored-procedure-based interface and
>> > having it enforce the semantics.
>>
>> Except not all DBs that
On Fri, Oct 27, 2006 at 11:51:50AM -0400, Derek Atkins wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > You'd be better off creating a stored-procedure-based interface and
> > having it enforce the semantics.
>
> Except not all DBs that we want to support have stored-procedures,
> so unf
On Fri, 2006-27-10 at 12:37 -0400, Derek Atkins wrote:
> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>
> > On Fri, 2006-27-10 at 11:58 -0400, Derek Atkins wrote:
> >
> >> I'm not sure what you mean by "cascade of DELETE operations".
> >> I think we CAN depend on the DB supporting transactions, but
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> On Fri, 2006-27-10 at 11:58 -0400, Derek Atkins wrote:
>
>> I'm not sure what you mean by "cascade of DELETE operations".
>> I think we CAN depend on the DB supporting transactions, but it
>> might depend on what level of TXN support we want/need.
>
>
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>> I still don't understand why you want to do this. What does it buy
>> us? It seems to add a LOT of complexity on the GnuCash side when
>> building up SQL queries. Instead of just being able to print out
>> "$table.${object}_id='$guid'" we'd need a
On Fri, 2006-27-10 at 11:58 -0400, Derek Atkins wrote:
> I'm not sure what you mean by "cascade of DELETE operations".
> I think we CAN depend on the DB supporting transactions, but it
> might depend on what level of TXN support we want/need.
With foreign keys, you can specify what should happen
On Fri, 2006-27-10 at 12:01 -0400, Derek Atkins wrote:
> Phil Longstaff <[EMAIL PROTECTED]> writes:
>
> >> I suppose we could use varchar; the guid has a fixed size so we know
> >> exactly how much space it requires. It's just an MD5 hash, so it's
> >> 128 bits, which is 16 bytes of binary or 32
Phil Longstaff <[EMAIL PROTECTED]> writes:
>> I suppose we could use varchar; the guid has a fixed size so we know
>> exactly how much space it requires. It's just an MD5 hash, so it's
>> 128 bits, which is 16 bytes of binary or 32 bytes of Hexstring.
>
> I am looking at having an int as the prim
Benoit Gregoire <[EMAIL PROTECTED]> writes:
> Depends what you use them for. Stored procedure used for additional
> referential integrity check are not a problem, and saved my ass more time
> than I can count. Stored procedures that write to the database and actually
> implement business logi
"Graham Leggett" <[EMAIL PROTECTED]> writes:
> Having said that I hope that the current XML file format be maintained as
> an export format - we check keep the thing in source control this way.
That's the plan.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Me
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> You'd be better off creating a stored-procedure-based interface and
> having it enforce the semantics.
Except not all DBs that we want to support have stored-procedures,
so unfortunately that's a non-starter.
-derek
--
Derek Atkins, SB '93 MI
Quoting "Jim C. Nasby" <[EMAIL PROTECTED]>:
> On Thu, Oct 26, 2006 at 03:33:37PM -0400, Derek Atkins wrote:
>> the list of requirements. Also, I dont think we can depend on stored
>> procedures; SQLite doesn't support them.
>
> Dumb question... why would someone want to run SQLite over the exist
On Fri, October 27, 2006 6:57 am, Jim C. Nasby wrote:
> Dumb question... why would someone want to run SQLite over the existing
> storage mechanism?
Because it's the same database engine for both local file and remote server?
Having said that I hope that the current XML file format be maintained
On Thu, Oct 26, 2006 at 03:33:37PM -0400, Derek Atkins wrote:
> the list of requirements. Also, I dont think we can depend on stored
> procedures; SQLite doesn't support them.
Dumb question... why would someone want to run SQLite over the existing
storage mechanism?
--
Jim C. Nasby, Database Ar
On Wed, Oct 25, 2006 at 08:39:18PM -0600, Mark Johnson wrote:
> Also, MySql has a bug which recently cost me some time. Foreign keys
> expressed as column constraints rather than table constraints are
> silently ignored! It has been reported multiple times (MySql bugs
> 11049, 7427, 4919, 1330
On Thu, Oct 26, 2006 at 05:49:36PM +0300, Ivars Grinbergs wrote:
> Derek Atkins wrote:
> > "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
> >
> >
> >>> 1) We don't need an AccountType table. AccountTypes are not data,
> >>>they are encoded in the application. There's no reason to add
> >>>
Derek Atkins wrote:
>Mark Johnson <[EMAIL PROTECTED]> writes:
>
>
>
>>I may be getting a bit ahead of the play here, since you are talking
>>about design still, and I am thinking about implementation of it in a
>>MySql backend.
>>
>>I was recently doing some research on storing GUIDs in MySQL.
Quoting Daniel Espinosa <[EMAIL PROTECTED]>:
> I'd checked the SQLite 3, and it doesn't support foreing keys, but
> triggers. Then may be in the future, after finish the SQL backend
> support in GC, we can create a "gnc-data-server" a la Evolution, in
> order to read, insert and update some record
On Thu, 2006-10-26 at 15:33 -0400, Derek Atkins wrote:
> Quoting Benoit Gregoire <[EMAIL PROTECTED]>:
> >
> > While I fully understand your feeling, sharing with other programs is
> > probably
> > the primary reason why users want a SQL in the first place. Since we KNOW
> > people will use it thi
2006/10/26, Ivars Grinbergs <[EMAIL PROTECTED]>:
Derek Atkins wrote:
> "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
>
>
>>> 1) We don't need an AccountType table. AccountTypes are not data,
>>>they are encoded in the application. There's no reason to add
>>>them to the database because
On Thursday 26 October 2006 15:51, Graham Leggett wrote:
> Benoit Gregoire wrote:
> > Yes you can (whith a "real" database). Checking that the sum of the
> > transaction's splits is 0 it trivial if all splits use the same
> > commodity, and mostly irrelevent if they don't. That's a really simple
Benoit Gregoire wrote:
Yes you can (whith a "real" database). Checking that the sum of the
transaction's splits is 0 it trivial if all splits use the same commodity,
and mostly irrelevent if they don't. That's a really simple stored
procedure.
And in the process, you restrict people to usi
> Actually, I think the primary reason users want SQL are to be able
> to run their own reports, multi-user, and automatic commits (saves
> on commit). I dont think that sharing the data read/write is high on
> the list of requirements. Also, I dont think we can depend on stored
> procedures; SQ
On Thursday 26 October 2006 10:49, Ivars Grinbergs wrote:
> Derek Atkins wrote:
> > "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
> >>> 1) We don't need an AccountType table. AccountTypes are not data,
> >>>they are encoded in the application. There's no reason to add
> >>>them to the dat
On Thursday 26 October 2006 14:49, Phil Longstaff wrote:
> On Thu, 2006-26-10 at 09:53 -0400, Derek Atkins wrote:
> > Mark Johnson <[EMAIL PROTECTED]> writes:
> > > I may be getting a bit ahead of the play here, since you are talking
> > > about design still, and I am thinking about implementation
Quoting Benoit Gregoire <[EMAIL PROTECTED]>:
>> You can't get enough data integrity from the database. For example,
>> you cannot define the database in a way to enforce balanced transactions.
>
> Yes you can (whith a "real" database). Checking that the sum of the
> transaction's splits is 0 it
On Thursday 26 October 2006 10:02, Derek Atkins wrote:
> "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
> >> 1) We don't need an AccountType table. AccountTypes are not data,
> >>they are encoded in the application. There's no reason to add
> >>them to the database because they are constan
On Thu, 2006-26-10 at 09:53 -0400, Derek Atkins wrote:
> Mark Johnson <[EMAIL PROTECTED]> writes:
>
> > I may be getting a bit ahead of the play here, since you are talking
> > about design still, and I am thinking about implementation of it in a
> > MySql backend.
> >
> > I was recently doing s
1 - 100 of 149 matches
Mail list logo
