On 09 Apr 2001 11:23:11 EDT, the world broke into rejoicing as
Derek Atkins <[EMAIL PROTECTED]> said:
> Christopher Browne <[EMAIL PROTECTED]> writes:
> > Consider the following control file:
> And how does one get this control file from client to client, user
> to user?
It obviously has to get
On Mon, 09 Apr 2001 12:00:58 CDT, the world broke into rejoicing as
[EMAIL PROTECTED] (Linas Vepstas) said:
> On Sat, Apr 07, 2001 at 12:01:31PM -0400, James LewisMoss was heard
> to remark:
>> This brings up something I was thinking.
>>
>> It'd be nice to stop using "files" as such to save gnuca
James LewisMoss <[EMAIL PROTECTED]> writes:
> From user to user you have to transfer some info. Whether it's a 2k
> file or a 90byte string doesn't seem like much of a difference to me.
>
> Jim
>From a UI perspective, I think that being able to transfer a '90byte
string', most likely in the fo
> On 09 Apr 2001 11:23:11 -0400, Derek Atkins <[EMAIL PROTECTED]> said:
Derek> Christopher Browne <[EMAIL PROTECTED]> writes:
>> Consider the following control file:
Derek> And how does one get this control file from client to client,
Derek> user to user? What happens if different users
On Sat, Apr 07, 2001 at 12:01:31PM -0400, James LewisMoss was heard to remark:
> This brings up something I was thinking.
>
> It'd be nice to stop using "files" as such to save gnucash data.
> Instead give the user a default path (which they can add to if they
> like) and search for books on that
On Sat, Apr 07, 2001 at 11:50:48AM -0400, Derek Atkins was heard to remark:
> I, too, like plan A. However instead of thinking about files, I'd
> prefer if we did keep things in the abstract 'book'. A book could be
Yes. Although its kind of hacked up at the moment, and needs cleaning,
writing
On Sun, Apr 08, 2001 at 12:12:50AM +1000, Conrad Canterford was heard to remark:
> Linas Vepstas wrote:
>
>
> Personally, I'd vote for Plan A (and not because I believe more work =
> better product).
>
> I'm already finding load times (both file and register) to be getting
> close to uncomforta
Christopher Browne <[EMAIL PROTECTED]> writes:
> Consider the following control file:
And how does one get this control file from client to client, user to
user? What happens if different users have different control files
on their clients while trying to access the same book?
However, I do li
On 07 Apr 2001 11:50:48 EDT, the world broke into rejoicing as
Derek Atkins <[EMAIL PROTECTED]> said:
> I, too, like plan A. However instead of thinking about files, I'd
> prefer if we did keep things in the abstract 'book'. A book could
> be a file, it could be a database, it could be a remote
I'd rather see all this configuration information stored again as part
of the Backend. Let's take a distributed, multi-client environment
(client/server) where we've got 10 years of data stored in books
closed every quarter. You now have a new user who wants to access the
data for the first time
> On 07 Apr 2001 12:01:31 -0400, James LewisMoss <[EMAIL PROTECTED]> said:
> On Fri, 6 Apr 2001 19:26:51 -0500 (CDT), [EMAIL PROTECTED] (Linas Vepstas) said:
Linas> Plan A: --- The kvp markup of plan C coupled to the
Linas> multi-file solution of plan F. In initial startup of gnuc
> On Fri, 6 Apr 2001 19:26:51 -0500 (CDT), [EMAIL PROTECTED] (Linas Vepstas) said:
Linas> Plan A: --- The kvp markup of plan C coupled to the
Linas> multi-file solution of plan F. In initial startup of gnucash,
Linas> only the 'current' book is loaded. If user asks for a report
Lin
I, too, like plan A. However instead of thinking about files, I'd
prefer if we did keep things in the abstract 'book'. A book could be
a file, it could be a database, it could be a remote database. You
don't know, and you shouldn't care. However, whatever we do should be
something that is tied
Linas Vepstas wrote:
Personally, I'd vote for Plan A (and not because I believe more work =
better product).
I'm already finding load times (both file and register) to be getting
close to uncomfortably long, and I have only just (as in this month)
exceed the 12 month mark. There is an option to
Hi,
A top request seems to be 'closing the books', and after a breif chat,
Bill suggested I write up the problem, and some possible solutions
(all hopefully easy to implement). In order from worst to best (?):
Plan F:
---
Simply 'delete' old transactions, and adjust the equity to make up f
15 matches
Mail list logo
