Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
> On Fri, Oct 27, 2006 at 09:32:42PM -0400, Derek Atkins wrote:
>> Hey,
>>
>> I was just trying the business reports and found two bugs
>> in trunk.
>>
>> Bug #1:
>>
>> [Menu] -> Reports -> Business -> Printable Invoice
>>
>> It comes up without an inv
On Fri, Oct 27, 2006 at 09:32:42PM -0400, Derek Atkins wrote:
> Hey,
>
> I was just trying the business reports and found two bugs
> in trunk.
>
> Bug #1:
>
> [Menu] -> Reports -> Business -> Printable Invoice
>
> It comes up without an invoice, but the report thinks it's
> trying to print inv
Hey,
I was just trying the business reports and found two bugs
in trunk.
Bug #1:
[Menu] -> Reports -> Business -> Printable Invoice
It comes up without an invoice, but the report thinks it's
trying to print invoice #0 instead of printing a message
saying that you need to choose an invoice.
Bu
On Fri, 2006-27-10 at 18:48 -0500, Daniel Espinosa wrote:
> 2006/10/26, Phil Longstaff <[EMAIL PROTECTED]>:
> > I've attached an updated DDL for the proposed SQL backend. I used MySQL
> > to test, and it creates the tables correctly.
>
> I have tested your DDL in PostgreSQL and it doesn't work, m
2006/10/26, Phil Longstaff <[EMAIL PROTECTED]>:
> I've attached an updated DDL for the proposed SQL backend. I used MySQL
> to test, and it creates the tables correctly.
I have tested your DDL in PostgreSQL and it doesn't work, may need to
modify it in a more portable area:
Command:
psql gnucash
> 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, Oct 27, 2006 at 01:02:52PM -0400, Derek Atkins wrote:
> Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>
> >>I don't have a good solution, at present ... just bringing it up.
> >>Probably the right thing is for SXes to just suck it up and model
> >>template transactions seperately from the "
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
On Fri, Oct 27, 2006 at 11:31:37AM -0400, Phil Longstaff wrote:
> I'm starting to take a look at the data abstraction layer to be used.
> The two candidates are libdbi and libgda. Here's what I have found so
> far:
>
> SQLite: latest stable version is 3.3.8 (Oct 9/06)
> MySQL: latest stable versi
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>> I don't have a good solution, at present ... just bringing it up.
>> Probably the right thing is for SXes to just suck it up and model
>> template transactions seperately from the "real"
>> accounts/transactions/splits, though there's some serious do
On Fri, Oct 27, 2006 at 12:31:40PM -0400, Josh Sled wrote:
> On Fri, 2006-10-27 at 12:04 -0400, Derek Atkins wrote:
> > Josh Sled <[EMAIL PROTECTED]> writes:
> >
> > > There's a deeper modeling issue with SXes. We use a seperate, parallel
> > > AccountGroup to store template transaction data, in w
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.
>
>
On Fri, 2006-10-27 at 12:04 -0400, Derek Atkins wrote:
> Josh Sled <[EMAIL PROTECTED]> writes:
>
> > There's a deeper modeling issue with SXes. We use a seperate, parallel
> > AccountGroup to store template transaction data, in which Accounts are
> > named as the string representation of the SXes
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
Josh Sled <[EMAIL PROTECTED]> writes:
> There's a deeper modeling issue with SXes. We use a seperate, parallel
> AccountGroup to store template transaction data, in which Accounts are
> named as the string representation of the SXes GUID, and contain
> Transactions with Splits which have their *re
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
I'm starting to take a look at the data abstraction layer to be used.
The two candidates are libdbi and libgda. Here's what I have found so
far:
SQLite: latest stable version is 3.3.8 (Oct 9/06)
MySQL: latest stable version is 5.0.24a
PostgreSQL: latest stable version is 8.1.5
DB abstraction lay
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 Thu, 2006-10-26 at 22:43 -0400, Phil Longstaff wrote:
> 6) I haven't looked too deeply into how a scheduled transaction is
> stored in XML and how that reflects its internal structure. It appears
> as though there is a gnc:schedxaction which stores the scheduled
> transaction, and that the tra
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
> >>>
On Thu, Oct 26, 2006 at 11:58:22PM -0400, Derek Atkins wrote:
> Quoting Benoit Gregoire <[EMAIL PROTECTED]>:
>
> > On Thursday 26 October 2006 22:43, Phil Longstaff wrote:
> >> 3) All object ids are (or should be) GUIDs. A GUID is represented by a
> >> set of 4 int fields. I use this instead of
33 matches
Mail list logo
