Re: GDA save missing records
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, it would cause all sorts of hassles if it turns out that the description on a transaction was arbitrarily truncated, or worse - the transaction was arbitrary ignored or dropped. I typically cut and paste full text strings from suppliers into invoice descriptions, and my suppliers are not limited by length, nor are their under any obligation to shorten their product descriptions if it causes hassles for me. This is a bit like the "640k is big enough for everybody" story, it isn't. :( Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature request from German list: Disable editing of transactions
my two cents I think it would be wise to collect a precise definition of the formal requirements before making any design decisions. ABSOLUTELY -- determining requirements is the first step in design. How about collecting translations of relevant sections of the actual laws in the wiki, to find the common denominator? But that is overly optimistic. It is very unlikely that there will not be inconsistency in the requirements. What we will need is not so much a system (hard coded) that can satisfy all of them but PROCEDURES how to accomplish what is required under various conditions. I'll give a concrete example using the "problem" stated --- a POSSIBLE solution. > >You are right, closed books and uneditable transactions seem to be tied >closely together. I wonder whether that is enough though, in terms of >requirements set by law in some countries. I think in Norway one must >not be able to _make_ any transactions prior to the book closing date >either. > >On the other hand: I close my books manually every other month, in order >to get the numbers for the VAT form. But occasionally I find an error in >the previous period and then I correct that and the closing transaction, >and send in a revision of the form if necessary. I am not sure how I am >supposed to properly correct errors in previous periods if transactions >are prohibited. > > Bastian -- you could, after the first closing and immediately preceding applying the "freeze" burn a copy of the file. Notice that I don't know whether the data indicating "frozen as of X date" would be kept in the books themselves or in some secondary file but it is data and will be in SOME file. In other words, the state immediately before the freeze can be saved and if necessary to later make changes (and then resubmit the tax reports) restored from this backup and a new "final" burned. BTW --- the process I am using here (I'm Treasurer of a 501(c)3 ) is to recognize that NO software freeze could stop me from editing the data (remember -- I made my living designing software). So I burn TWO copies and give one of these to another party. In the event of legal questions these could be compared. Michael ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature request from German list: Disable editing of transactions
Thilo Pfennig wrote: Maybe this is a misunderstanding but what I mean is that if I make an entry into the account "bank" I think this should still be visible, because only if it wont there would be an error. I think oen should distinct the real bank account and the bank account in GnuCash. Sure these two should match, but for GnuCash the authorative one should be the GnuCash "bank" account, shouldnt it? The authoritative account is the one that is considered "right" by an auditor, and that would be the bank statement, not the gnucash account. > If tentries are falshe the user should correct them but this should be visible. For what purpose? The only thing an auditor is interested in is whether the account matches the bank statement. If the account contains a whole lot of extra entries that doesn't match the bank statement, that makes the auditor's life more difficult, and in turn you will get a bigger auditing bill at the end of the year [1]. It is only after the signoff / locking / reconcilation process that it becomes important to track changes, as this affects external procedures such as interim reporting and VAT returns. Of course if a user wants to implement an "all accounts are locked" policy, then they should be empowered to do so, but it certainly shouldn't be insisted on for everybody. [1] This I found first hand in a project, one of the basic requirements of the project was to reduce the auditing bill of the company concerned. If they are just editable without being visible this would make all accounts that interact with bank alsio being editable, because only if one can check both accounts for correctness one is able to make a statement about the overall correctness of the book keeping. At least thats what I learned. The problem is that you cannot make a statement about the overall "correctness" of a transaction until both sides have been reconciled, and that usually happens at different dates. It would be quite valid to "lock" the split in the bank account after the bank account was reconciled, but keep the option to move the opposite split elsewhere if it was determined that the amount had been allocated to the wrong place. Once it is allocated to the right place, the other side of the transaction is reconciled, and now both splits become locked. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: PostgreSQL empty slots table
On Feb 11, 2008, at 9:09 PM, Mark Johnson wrote: I'd be interested in any benchmarks you have. Re SQL statement length: the mysql document says there is a 16MB limit and I didn't see any limit in the sqlite documentation. Is there a way of doing something like: SELECT DISTINCT tx_guid FROM splits /* and save the results */ SELECT * FROM transansactions WHERE guid IN results_from_above_query /* and return the results */ SELECT * FROM splits WHERE tx_guid IN results_from_above_query /* and return the results */ i.e. have the engine cache the results of the 1st query and reuse it in subsequent queries without needing to recompute? Use a TEMP table to store the results of the first query. Note that you'll get better results on the 2nd and 3rd queries if you update stats on the temp table; that would be ANALYZE in Postgres; not sure about MySQL. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA save missing records
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 example). gnc is not, and should not be, a doc mgmt system. I want fast, fast retrieval and summarization. Having a place to store a reference to a doc is a great idea; plugging up the data with the docs, not so much. Of course, it is unforgiveable to just drop rows. Even silently truncating data is pretty dubious. Don't know Postgres and Mysql; can't we throw an exception so we have a chance to do the right thing (what the user needs)? I'd ask the developers to pick some reasonable size for each column. Then publish the schema. Granted this is a big change from the unlimited everything, but it seems necessary. If I don't like your column size, I should be able to ALTER TABLE and set my own favorites, so please do not hard-code the column sizes into the code. Keith, Guelph On Feb 18, 2008 5:45 AM, Graham Leggett <[EMAIL PROTECTED]> wrote: > 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, it would cause all sorts of hassles if it > turns out that the description on a transaction was arbitrarily > truncated, or worse - the transaction was arbitrary ignored or dropped. > > I typically cut and paste full text strings from suppliers into invoice > descriptions, and my suppliers are not limited by length, nor are their > under any obligation to shorten their product descriptions if it causes > hassles for me. > > This is a bit like the "640k is big enough for everybody" story, it > isn't. :( > > Regards, > Graham > -- > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA save missing records
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 hacks -- Oracle Text, for example). gnc is not, and should not be, a doc mgmt system. I want fast, fast retrieval and summarization. Having a place to store a reference to a doc is a great idea; plugging up the data with the docs, not so much. Of course, it is unforgiveable to just drop rows. Even silently truncating data is pretty dubious. Don't know Postgres and Mysql; can't we throw an exception so we have a chance to do the right thing (what the user needs)? I'd ask the developers to pick some reasonable size for each column. Then publish the schema. Granted this is a big change from the unlimited everything, but it seems necessary. If I don't like your column size, I should be able to ALTER TABLE and set my own favorites, so please do not hard-code the column sizes into the code. The problem with this is that it introduces inconsistency into the code. The XML backend has no concept of line lengths, and is so "unlimited". The problem was originally found when an attempt was made to import this "unlimited" data into a "limited" system, such as the current DB system. Suddenly we have introduced the possibility that perfectly valid data in one backend is no longer valid in another. Add to that a user ability to change the line lengths and suddenly all bets are off. Fixed length string widths are an optimisation that helps if you are manipulating fixed length strings, but if you aren't - such as with a description in a register - the fixed length serves no purpose at all. As someone who spends a lot of time tracking down nasty problems in software, I can tell you that this is exactly one of those seemingly harmless issues that can cause some very difficult to find, and therefore very expensive bugs in systems. In this case, it was only found because mysql and postgresql have different behaviour when string lengths are too long, and that was found by a very lucky accident. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
GDA: string lengths (was Re: GDA save missing records)
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 searching (other than with special >> hacks -- Oracle Text, for example). >> >> gnc is not, and should not be, a doc mgmt system. I want fast, fast >> retrieval and summarization. Having a place to store a reference to a >> doc is a great idea; plugging up the data with the docs, not so much. >> >> Of course, it is unforgiveable to just drop rows. Even silently >> truncating data is pretty dubious. Don't know Postgres and Mysql; >> can't we throw an exception so we have a chance to do the right thing >> (what the user needs)? >> >> I'd ask the developers to pick some reasonable size for each column. >> Then publish the schema. Granted this is a big change from the >> unlimited everything, but it seems necessary. If I don't like your >> column size, I should be able to ALTER TABLE and set my own >> favorites, so please do not hard-code the column sizes into the code. > > The problem with this is that it introduces inconsistency into the > code. The XML backend has no concept of line lengths, and is so > "unlimited". The problem was originally found when an attempt was made > to import this "unlimited" data into a "limited" system, such as the > current DB system. > > Suddenly we have introduced the possibility that perfectly valid data > in one backend is no longer valid in another. Add to that a user > ability to change the line lengths and suddenly all bets are off. > > Fixed length string widths are an optimisation that helps if you are > manipulating fixed length strings, but if you aren't - such as with a > description in a register - the fixed length serves no purpose at all. > > As someone who spends a lot of time tracking down nasty problems in > software, I can tell you that this is exactly one of those seemingly > harmless issues that can cause some very difficult to find, and > therefore very expensive bugs in systems. In this case, it was only > found because mysql and postgresql have different behaviour when > string lengths are too long, and that was found by a very lucky accident. 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 creating them. Of course, I could also just try varchar(2048) instead of varchar(50), which should also be sufficient. I assume that the db tries to optimize space so that storing a 1000 char string and storing a 1 char string in a varchar(2048) don't use the same amount of space. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: string lengths (was Re: GDA save missing records)
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 creating them. Of course, I could also just try varchar(2048) instead of varchar(50), which should also be sufficient. I assume that the db tries to optimize space so that storing a 1000 char string and storing a 1 char string in a varchar(2048) don't use the same amount of space. Generally, the database doesn't do this - it will allocate 2048 chars, whether you use 1 char or 1000. The upside of this is that it is very quick, the downside is that it wastes a lot of space. Unlimited or "large" text strings are optimised, only because they have to be to be stored practically. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: string lengths (was Re: GDA save missing records)
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 can support a 2 byte string length, then why not choose the biggest size available? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: string lengths (was Re: GDA save missing records)
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 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 creating them. > > Of course, I could also just try varchar(2048) instead of varchar(50), > > which should also be sufficient. I assume that the db tries to optimize > > space so that storing a 1000 char string and storing a 1 char string in > > a varchar(2048) don't use the same amount of space. > > Generally, the database doesn't do this - it will allocate 2048 chars, > whether you use 1 char or 1000. The upside of this is that it is very > quick, the downside is that it wastes a lot of space. > > Unlimited or "large" text strings are optimised, only because they have > to be to be stored practically. > > Regards, > Graham > -- > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: cannot find -lgnc-backend-file-utils
Hi,
By any chance are you running "make -j 2" (or make -j with any
number > 1)? I only ask because it's possible that there's a
race condition and it's trying to build the second library
before the first.
-derek
Quoting Martin Meyer <[EMAIL PROTECTED]>:
> Hi all!
>
> I'm working on a Gentoo box and I'm having issues getting gnucash
> 2.2.3 to build. The arch is amd64 (i.e. x86_64), and the processor is
> a core 2 quad. I spoke with jsled on IRC for a while and I seem to
> have stumped him on this issue. You can find the IRC log here:
>
> http://lists.gnucash.org/logs/2008/02/2008-02-18.html#T21:50:18
>
> Here's my build log from right before the failure:
>
> libtool: install: warning: relinking `libgncmod-backend-file.la'
> (cd
> /var/tmp/portage/app-office/gnucash-2.2.3-r1/work/gnucash-2.2.3/src/backend/file;
> /bin/sh ../../../libtool --tag=CC --mode=relink
> x86_64-pc-linux-gnu-gcc -I.. -I../.. -DLOCALE_DIR="/usr/share/locale"
> -I../../../src/backend -I../../../src/engine -I../../../src/core-utils
> -I../../../lib/libc -I/usr/include/libxml2 -I../../../lib/libqof/qof
> -I../../../lib/libqof/qof -pthread -I/usr/include/glib-2.0
> -I/usr/lib64/glib-2.0/include -DORBIT2=1 -pthread
> -I/usr/include/gconf/2 -I/usr/include/orbit-2.0
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> -Wdeclaration-after-statement -Wno-pointer-sign -D_FORTIFY_SOURCE=2
> -march=nocona -pipe -g -O2 -Wall -Wunused -Wmissing-prototypes
> -Wmissing-declarations -Wno-unused -module -avoid-version -g -o
> libgncmod-backend-file.la -rpath /usr/lib64/gnucash
> gnc-backend-file.lo -pthread -Wl,--export-dynamic -lgthread-2.0 -lrt
> -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgconf-2 -lglib-2.0
> -lxml2 ../../../src/engine/libgncmod-engine.la
> ../../../src/core-utils/libgnc-core-utils.la
> ../../../src/backend/file/libgnc-backend-file-utils.la
> ../../../lib/libqof/qof/libgnc-qof.la -lpopt -lm -lm -inst-prefix-dir
> /var/tmp/portage/app-office/gnucash-2.2.3-r1/image/)
> x86_64-pc-linux-gnu-gcc -shared .libs/gnc-backend-file.o -Wl,--rpath
> -Wl,/usr/lib64/gnucash
> -L/var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64
> -L/usr/lib64 -lgthread-2.0 -lrt -lgobject-2.0 -lgmodule-2.0 -ldl
> -lgconf-2 -lglib-2.0 -lxml2
> -L/var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64/gnucash
> -L/usr/lib64/gnucash -lgncmod-engine -lgnc-core-utils
> -lgnc-backend-file-utils -lgnc-qof -lpopt -lm -pthread -pthread
> -march=nocona -pthread -Wl,--export-dynamic -Wl,-soname
> -Wl,libgncmod-backend-file.so -o .libs/libgncmod-backend-file.so
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../../x86_64-pc-linux-gnu/bin/ld:
> cannot find -lgnc-backend-file-utils
> collect2: ld returned 1 exit status
> libtool: install: error: relink `libgncmod-backend-file.la' with the
> above command before installing it
> make[6]: *** [install-pkglibLTLIBRARIES] Error 1
> make[6]: *** Waiting for unfinished jobs
> x86_64-pc-linux-gnu-gcc -shared .libs/gnc-account-xml-v2.o
> .libs/gnc-book-xml-v2.o .libs/gnc-budget-xml-v2.o
> .libs/gnc-commodity-xml-v2.o .libs/gnc-freqspec-xml-v2.o
> .libs/gnc-lot-xml-v2.o .libs/gnc-pricedb-xml-v2.o
> .libs/gnc-recurrence-xml-v2.o .libs/gnc-schedxaction-xml-v2.o
> .libs/gnc-transaction-xml-v2.o .libs/io-example-account.o
> .libs/io-gncxml-gen.o .libs/io-gncxml-v1.o .libs/io-gncxml-v2.o
> .libs/io-utils.o .libs/sixtp-dom-generators.o
> .libs/sixtp-dom-parsers.o .libs/sixtp-stack.o
> .libs/sixtp-to-dom-parser.o .libs/sixtp-utils.o .libs/sixtp.o
> -Wl,--rpath -Wl,/usr/lib64/gnucash
> -L/var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64
> -L/usr/lib64 -lgthread-2.0 -lrt -lgobject-2.0 -lgmodule-2.0 -ldl
> -lgconf-2 -lglib-2.0 -lxml2
> -L/var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64/gnucash
> -L/usr/lib64/gnucash -lgncmod-engine -lgnc-core-utils -lgnc-qof -lpopt
> -lm -pthread -pthread -march=nocona -pthread -Wl,--export-dynamic
> -Wl,-soname -Wl,libgnc-backend-file-utils.so.0 -o
> .libs/libgnc-backend-file-utils.so.0.0.0
> /usr/bin/install -c .libs/libgnc-backend-file-utils.so.0.0.0T
> /var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64/libgnc-backend-file-utils.so.0.0.0
> (cd /var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64 && {
> ln -s -f libgnc-backend-file-utils.so.0.0.0
> libgnc-backend-file-utils.so.0 || { rm -f
> libgnc-backend-file-utils.so.0 && ln -s
> libgnc-backend-file-utils.so.0.0.0 libgnc-backend-file-utils.so.0; };
> })
> (cd /var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64 && {
> ln -s -f libgnc-backend-file-utils.so.0.0.0
> libgnc-backend-file-utils.so || { rm -f libgnc-backend-file-utils.so
> && ln -s libgnc-backend-file-utils.so.0.0.0
> libgnc-backend-file-utils.so; }; })
> /usr/bin/install -c .libs/libgnc-backend-file-utils.lai
> /var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64/libgnc-backend-file-utils.la
> libtool: install: warning: remember to run `libtool --finish /usr/lib64'
> make[6]: Leaving directory
> `/
cannot find -lgnc-backend-file-utils
Hi all!
I'm working on a Gentoo box and I'm having issues getting gnucash
2.2.3 to build. The arch is amd64 (i.e. x86_64), and the processor is
a core 2 quad. I spoke with jsled on IRC for a while and I seem to
have stumped him on this issue. You can find the IRC log here:
http://lists.gnucash.org/logs/2008/02/2008-02-18.html#T21:50:18
Here's my build log from right before the failure:
libtool: install: warning: relinking `libgncmod-backend-file.la'
(cd
/var/tmp/portage/app-office/gnucash-2.2.3-r1/work/gnucash-2.2.3/src/backend/file;
/bin/sh ../../../libtool --tag=CC --mode=relink
x86_64-pc-linux-gnu-gcc -I.. -I../.. -DLOCALE_DIR="/usr/share/locale"
-I../../../src/backend -I../../../src/engine -I../../../src/core-utils
-I../../../lib/libc -I/usr/include/libxml2 -I../../../lib/libqof/qof
-I../../../lib/libqof/qof -pthread -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -DORBIT2=1 -pthread
-I/usr/include/gconf/2 -I/usr/include/orbit-2.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-Wdeclaration-after-statement -Wno-pointer-sign -D_FORTIFY_SOURCE=2
-march=nocona -pipe -g -O2 -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations -Wno-unused -module -avoid-version -g -o
libgncmod-backend-file.la -rpath /usr/lib64/gnucash
gnc-backend-file.lo -pthread -Wl,--export-dynamic -lgthread-2.0 -lrt
-lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgconf-2 -lglib-2.0
-lxml2 ../../../src/engine/libgncmod-engine.la
../../../src/core-utils/libgnc-core-utils.la
../../../src/backend/file/libgnc-backend-file-utils.la
../../../lib/libqof/qof/libgnc-qof.la -lpopt -lm -lm -inst-prefix-dir
/var/tmp/portage/app-office/gnucash-2.2.3-r1/image/)
x86_64-pc-linux-gnu-gcc -shared .libs/gnc-backend-file.o -Wl,--rpath
-Wl,/usr/lib64/gnucash
-L/var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64
-L/usr/lib64 -lgthread-2.0 -lrt -lgobject-2.0 -lgmodule-2.0 -ldl
-lgconf-2 -lglib-2.0 -lxml2
-L/var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64/gnucash
-L/usr/lib64/gnucash -lgncmod-engine -lgnc-core-utils
-lgnc-backend-file-utils -lgnc-qof -lpopt -lm -pthread -pthread
-march=nocona -pthread -Wl,--export-dynamic -Wl,-soname
-Wl,libgncmod-backend-file.so -o .libs/libgncmod-backend-file.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../../x86_64-pc-linux-gnu/bin/ld:
cannot find -lgnc-backend-file-utils
collect2: ld returned 1 exit status
libtool: install: error: relink `libgncmod-backend-file.la' with the
above command before installing it
make[6]: *** [install-pkglibLTLIBRARIES] Error 1
make[6]: *** Waiting for unfinished jobs
x86_64-pc-linux-gnu-gcc -shared .libs/gnc-account-xml-v2.o
.libs/gnc-book-xml-v2.o .libs/gnc-budget-xml-v2.o
.libs/gnc-commodity-xml-v2.o .libs/gnc-freqspec-xml-v2.o
.libs/gnc-lot-xml-v2.o .libs/gnc-pricedb-xml-v2.o
.libs/gnc-recurrence-xml-v2.o .libs/gnc-schedxaction-xml-v2.o
.libs/gnc-transaction-xml-v2.o .libs/io-example-account.o
.libs/io-gncxml-gen.o .libs/io-gncxml-v1.o .libs/io-gncxml-v2.o
.libs/io-utils.o .libs/sixtp-dom-generators.o
.libs/sixtp-dom-parsers.o .libs/sixtp-stack.o
.libs/sixtp-to-dom-parser.o .libs/sixtp-utils.o .libs/sixtp.o
-Wl,--rpath -Wl,/usr/lib64/gnucash
-L/var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64
-L/usr/lib64 -lgthread-2.0 -lrt -lgobject-2.0 -lgmodule-2.0 -ldl
-lgconf-2 -lglib-2.0 -lxml2
-L/var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64/gnucash
-L/usr/lib64/gnucash -lgncmod-engine -lgnc-core-utils -lgnc-qof -lpopt
-lm -pthread -pthread -march=nocona -pthread -Wl,--export-dynamic
-Wl,-soname -Wl,libgnc-backend-file-utils.so.0 -o
.libs/libgnc-backend-file-utils.so.0.0.0
/usr/bin/install -c .libs/libgnc-backend-file-utils.so.0.0.0T
/var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64/libgnc-backend-file-utils.so.0.0.0
(cd /var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64 && {
ln -s -f libgnc-backend-file-utils.so.0.0.0
libgnc-backend-file-utils.so.0 || { rm -f
libgnc-backend-file-utils.so.0 && ln -s
libgnc-backend-file-utils.so.0.0.0 libgnc-backend-file-utils.so.0; };
})
(cd /var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64 && {
ln -s -f libgnc-backend-file-utils.so.0.0.0
libgnc-backend-file-utils.so || { rm -f libgnc-backend-file-utils.so
&& ln -s libgnc-backend-file-utils.so.0.0.0
libgnc-backend-file-utils.so; }; })
/usr/bin/install -c .libs/libgnc-backend-file-utils.lai
/var/tmp/portage/app-office/gnucash-2.2.3-r1/image//usr/lib64/libgnc-backend-file-utils.la
libtool: install: warning: remember to run `libtool --finish /usr/lib64'
make[6]: Leaving directory
`/var/tmp/portage/app-office/gnucash-2.2.3-r1/work/gnucash-2.2.3/src/backend/file'
make[5]: *** [install-am] Error 2
make[5]: Leaving directory
`/var/tmp/portage/app-office/gnucash-2.2.3-r1/work/gnucash-2.2.3/src/backend/file'
make[4]: *** [install-recursive] Error 1
make[4]: Leaving directory
`/var/tmp/portage/app-office/gnucash-2.2.3-r1/work/gnucash-2.2.3/src/backend/file'
make[3]: *** [install-recursive] Error 1
make[3]: Leav
Re: GDA: string lengths (was Re: GDA save missing records)
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 for VARCHAR type are dependent on the MySQL version, and are variable, not padded. PostgreSQL 8.3 documentation states: "If one explicitly casts a value to character varying(n) [i.e. VARCHAR] or character(n) [i.e. CHAR] , then an over-length value will be truncated to n characters without raising an error. ... If character varying is used without length specifier, the type accepts strings of any size. The latter is a PostgreSQL extension." So in PostgreSQL, if you specify a length, that's what gets stored, but if you don't specify a length, anything goes. SQLite states: "SQLite does not enforce the length of a VARCHAR. You can declare a VARCHAR(10) and SQLite will be happy to let you put 500 characters in it. And it will keep all 500 characters intact - it never truncates." So size definitions won't matter in SQLite. Cheers, David --- Graham Leggett <[EMAIL PROTECTED]> wrote: > 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 can support a 2 > byte string length, then why not choose the biggest size available? > > Regards, > Graham > -- > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
