gnucash-user Digest, Vol 68, Issue 22

[Alejandro Vidal]

help

gnucash-user-request at gnucash.org escribió:
> Send gnucash-user mailing list submissions to
> 	gnucash-user at gnucash.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.gnucash.org/mailman/listinfo/gnucash-user
> or, via email, send a message with subject or body 'help' to
> 	gnucash-user-request at gnucash.org
>
> You can reach the person managing the list at
> 	gnucash-user-owner at gnucash.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gnucash-user digest..."
>
>
> Today's Topics:
>
>    1. Register display oddity (Fred Bone)
>    2. Re: String lengths in the SQL backend (Keith A. Milner)
>    3. Re: Register display oddity (Charles Day)
>    4. Getting the "Num" column width to persist between sessions?
>       (Adam Funk)
>    5. Re: Getting the "Num" column width to persist between
>       sessions? (Derek Atkins)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 20 Nov 2008 09:18:21 -0000
> From: "Fred Bone" <Fred.Bone at dial.pipex.com>
> Subject: Register display oddity
> To: gnucash-user at gnucash.org
> Message-ID: <49252B5D.26538.8B343EE at Fred.Bone.dial.pipex.com>
> Content-Type: text/plain; charset=US-ASCII
>
> I have recently entered some transactions in TND and am seeing some 
> display quirks. It appears that the number of figures displayed after the 
> point depends, not on the currency of the register, but on the currency 
> in which the transaction was entered.
>
> TND, unusually, are divided into thousandths ("milims").
>
> My initial purchase of TND was in cash (GBP150 bought me TND321). The 
> resulting transaction, which I entered from the GBP side, displays as 
> "321.00" on the TND cash register, both in the "Deposit" column and in 
> the "Balance" column. All remaining transactions were entered from the 
> "TND" side, and display with 3 figures after the point. This includes the 
> register for the (GBP) credit card with which I settled a couple of hotel 
> bills.
>
> Do other people regard this as a (very minor) display bug, or am I 
> missing something that would make this behaviour essential?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 20 Nov 2008 09:26:48 +0000
> From: "Keith A. Milner" <maillist at superlative.org>
> Subject: Re: String lengths in the SQL backend
> To: gnucash-user at gnucash.org
> Message-ID: <200811200926.48930.maillist at superlative.org>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Wednesday 19 November 2008 15:33:13 Derek Atkins wrote:
>
>   
>> Having said that, we shouldn't rule out users accessing the data
>> out from under GnuCash, at least in a read-only means.  I still
>> believe that external tools should not be writing data into the
>> GnuCash database.
>>     
>
> I totally agree with this.
>
> A database schema should not be confused with an API. It's a common mistake 
> and I've lost count of the times I heard people say "they both use Oracle" 
> when discussing application integration, the assumption being that because 
> two applications happen to share the same database system they will 
> automatically integrate with each other.
>
> The reality is application database schemas change and often for good reason. 
> They should not be 100% relied on even, arguably, for reading. Writing to a 
> database used by an application is very likely to break things badly unless 
> you know what you are doing. If you know what you are doing you might do it 
> by hand as an expedient to fix a specific problem but automated tools or 
> external applications writing to an application's database is a recipe for 
> disaster.
>
> I know it is possible to mitigate against this by careful applications of 
> views, use of stored procedures and so on to create a database layer API, but 
> this is the wrong way to do it. If you are going to commit the time and 
> energy to create an API, it should really be independent of the application's 
> own data storage.
>
> Cheers,
>
>