mdbtools-dev

[mdb-dev] Linked Tables

[Phil M. <phi...@gm...>]

Hi,

Like many others I've found mdb-tools and think it is indeed a great
and well-needed piece of software, very well done.

I'm connecting to an MDB on a mounted windows share from a Fedora Core
box and have been able to pull the data that I need so far.

I know that linked tables is one feature that is mentioned for future
release, but I was just wondering how soon/close this is to being
available?

I'd also like to contribute to the project as it looks like something
I'll be needing to use in my work and would like help others to
leverage this great software as they require.

Regards,

Phil

[mdb-dev] mdbtools 0.6pre1 / unixODBC / ms-access mdb

[Beni B. <ben...@sw...>]

SGkgbGlzdCwKCkknbSBjdXJyZW50bHkgdHJ5aW5nIHRvIGFjY2VzcyBhIG1kYiBmaWxlIG9uIGEg
d2luMmsgYm94IG1vdW50ZWQgdXNpbmcgc2FtYmEgdG8gYSBzdXNlLWJveC4gSSd2ZSBtYW5hZ2Vk
IHRvIGNvbm5lY3QgdG8gdGhlIG1kYiB1c2luZyBpc3FsLiBCdXQgSSBnZXQgYSBzZWdtZW50YXRp
b24gZmF1bHQgYWZ0ZXIgdGhlIGZpcnN0IHBhcnQgb2YgdGhlIHJlc3VsdCBpcyBkaXNwbGF5ZWQu
CgpJJ3ZlIG5vdCBtYW5hZ2VkIHRvIGNvbm5lY3QgdG8gdGhlIG1kYiB1c2luZyBQSFAgd2l0aCB1
bml4T0RCQyBhbmQgdGhlIG1kYnRvb2xzIGRyaXZlci4gSSBnZXQgdGhlIGVycm9yOiAiU1FMIGVy
cm9yOiBbdW5peE9EQkNdQ291bGQgbm90IGZpbmQgRGF0YWJhc2UgcGFyYW1ldGVyLCBTUUwgc3Rh
dGUgMDgwMDEgaW4gU1FMQ29ubmVjdCIKCm15IG9kYmMuaW5pOgpbRUhEXQpEZXNjcmlwdGlvbiA9
IEVIRApEcml2ZXIgPSBNREJUb29sc09EQkMKRGF0YWJhc2UgPSAvbW50L2VoZC9TSEQvaWhkLm1k
YgpTZXJ2ZXJuYW1lID0gbG9jYWxob3N0ClVzZXJOYW1lID0KUGFzc3dvcmQgPQpQb3J0ID0gNTQz
MgoKb2RiY2luc3QuaW5pOgpbTURCVG9vbHNPREJDXQpEZXNjcmlwdGlvbiA9IE1EQiBUb29scyBP
REJDIGRyaXZlcnMKRHJpdmVyID0gL3Vzci9saWIvbGlibWRib2RiYy5zby4wClNldHVwID0KRmls
ZVVzYWdlID0gMQpDUFRpbWVvdXQgPQpDUFJldXNlID0KCnRlc3QucGhwOgokZGIgPSBvZGJjX2Nv
bm5lY3QoIkVIRCIsIiIsIiIpOwokcXVlcnkgPSAic2VsZWN0IEV2X1Byb2plY3ROdW1iZXIgZnJv
bSBFdmVudCI7CiRyZXN1bHQgPSBvZGJjX2V4ZWMoJGRiLCAkcXVlcnkpOwokcmVwb3J0ID0gb2Ri
Y19mZXRjaF9yb3coJHJlc3VsdCk7CmVjaG8gb2RiY19yZXN1bHQoJHJlc3VsdCwgMSk7Cm9kYmNf
Y2xvc2UoJGRiKTsKCgpEb2VzIGFueWJvZHkgaGF2ZSBhbiBpZGVhIHdoYXQgSSBjYW4gZG8gdG8g
Z2V0IHRoaXMgd29ya2luZz8KCgoKSSd2ZSByZWFkIGZyb20gdGhlIGJ1ZyB3aXRoIHRoZSB1bmRl
cnNjb3JlcyBpbiB0YWJsZS9jb2x1bW4gLW5hbWVzIGhlcmU6IGh0dHA6Ly9icnlhbm1pbGxzLm5l
dDo4MDg2L2FyY2hpdmVzLzIwMDMvMTEvbWljcm9zb2Z0LWFjY2Vzcy1kYXRhYmFzZS11c2luZy1s
aW51eC1hbmQtcGhwLwoKSSd2ZSBub3cgY29tcGlsZWQgdGhlIDAuNnByZTEgcmVsZWFzZS4gSXMg
dGhpcyBidWcgZml4ZWQgdGhlcmU/CgoKClRoYW5rcyBmb3IgeW91ciBpbnB1dHMgaW4gQWR2YW5j
ZSEKCgpSZWdhcmRzLApCZW5pCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KVGhpcyBtZXNzYWdlIG1heSBjb250YWluIGxlZ2FsbHkg
cHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgCmluZm9ybWF0aW9uIGFuZCBpcyB0aGVyZWZvcmUg
YWRkcmVzc2VkIHRvIHRoZSBuYW1lZCBwZXJzb25zIG9ubHkuIApUaGUgcmVjaXBpZW50IHNob3Vs
ZCBpbmZvcm0gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSwgCmlmIGhlL3NoZSBp
cyBub3QgbmFtZWQgYXMgYWRkcmVzc2VlLiAKVGhlIHNlbmRlciBkaXNjbGFpbXMgYW55IGFuZCBh
bGwgbGlhYmlsaXR5IGZvciB0aGUgaW50ZWdyaXR5IAphbmQgcHVuY3R1YWxpdHkgb2YgdGhpcyBt
ZXNzYWdlLiAKVGhlIHNlbmRlciBoYXMgYWN0aXZhdGVkIGFuIGF1dG9tYXRpYyB2aXJ1cyBzY2Fu
bmluZyBieSAKTWVzc2FnZWxhYnMsIGJ1dCBkb2VzIG5vdCBndWFyYW50ZWUgdGhlIHZpcnVzIGZy
ZWUgCnRyYW5zbWlzc2lvbiBvZiB0aGlzIG1lc3NhZ2UuCg==

[mdb-dev] Problems with small numbers

[Rafael de P. S. <ra...@rp...>]

HI all,

I just subscripted in this list to report I problem I found.

I have a mdb with some tables where the values are like 1.045e-18. The 
problem is, when I export the table with mdb-export I got just 0.000000 
for these small values.

At a first look I could not found the source of the problem in 
mdb-export but I guess is something related with the format used for 
double values. Is there a way to specify a 'scientific' format for the 
doubles in order to outline this problem?

Thanks in advance.

-- 
:: MSc(Eng)  Rafael de Pelegrini Soares
:: ra...@rp...  -  www.rps.eng.br

[mdb-dev] Question concerning the use of MdbSQL

[Horst K. <md...@kn...>]

In your examples you use 

MdbSQL* sql=mdb_sql_init();

According to the documentation of mdb_init()  it should be called only once in 
an application.   mdb_sql_init() calls mdb_init() so  I presume it should 
also be called only once from an application.

If I need to open 2 or more Access databases at the same time, I will need 
more than one handle (is this really correct?). 

Is creating a second handle with the following code safe?

MdbSQL *sql= (MdbSQL *) g_malloc0(sizeof(MdbSQL));
 sql->columns = g_ptr_array_new();
 sql->tables = g_ptr_array_new();
 sql->sarg_tree = NULL;
 sql->sarg_stack = NULL;
 sql->max_rows = -1;
    
and then using it with 
mdb_sql_open(sql,"mydatabase.mdb");


Regards

Horst

[mdb-dev] Patch for mdb-sql.cpp

[Horst K. <md...@kn...>]

this patch fixes a bug when using dump_results() / turning off pretty 
printing. In this case the values of the last row weren't printed

Horst

[mdb-dev] Patch for mdbsql.h

[Horst K. <md...@kn...>]

Enclosed is a patch for mdbsql.h to work with c++. Otherwise the shared 
library can't be used


Horst

[mdb-dev] Patch for mdbsql.h

[Horst K. <md...@kn...>]

Re: [mdb-dev] latest CVS version crashes

[Horst K. <md...@kn...>]

Am Freitag 25 M=E4rz 2005 05:30 schrieb Jeff Smith:
> --- Horst Knorr <md...@kn...> wrote:
> > installation of the latest CVS version (March 22) works ok, but start=
ing
> > any application I get a memory allocation error.
>
> Horst,
>   I made a fix to mdb_find_row very late on the 22nd which may affect t=
his.
> Could you please update your cvs and try again.  If this still persists=
,
> a gdb backtrace would be more useful to me than the valgrind one.  Plea=
se
> let me know what you find out.
>
>  -- Jeff Smith

Seems to work correctly now.

Thanks

Horst

Re: [mdb-dev] help needed (how to deal with ldb files)

[Sam M. <pa...@gm...>]

I thought ldb was the lock file for access?

Try removing the LDB file, might solve your issues.

Sam

On Thu, 24 Mar 2005 01:12:24 +0200, Mindaugas Kirsanskas
<Min...@ha...> wrote:
> Currently i have big problem retrieving data from access files. One
> application in our organization generates access databases (new database
> every week) with statistical information that I need to transfer to
> mysql database for processing and reporting. That application constantly
> keeps connection to the last mdb file until week changes, but I need
> that data from access at least every hour. I'm using mdbtools and my own
> perl application to migrate data to mysql, before that I copy that last
> mdb file together with ldb one to different location, not accessible for
> that application. Somehow MS made database corrupted until someone uses
> it, so is it possible to drop that connection or anything...? I can
> retrieve db schema from access database but not a single record,
> although if I open it with MS Access - I can see all data.
>=20
> Thanks in advance
>=20
> Mindaugas K.
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&opclick
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
>

Re: [mdb-dev] latest CVS version crashes

[Jeff S. <why...@ya...>]

--- Horst Knorr <md...@kn...> wrote:
> installation of the latest CVS version (March 22) works ok, but starting any 
> application I get a memory allocation error.

Horst,
  I made a fix to mdb_find_row very late on the 22nd which may affect this.
Could you please update your cvs and try again.  If this still persists,
a gdb backtrace would be more useful to me than the valgrind one.  Please
let me know what you find out.

 -- Jeff Smith


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

[mdb-dev] help needed (how to deal with ldb files)

[Mindaugas K. <Min...@ha...>]

Currently i have big problem retrieving data from access files. One
application in our organization generates access databases (new database
every week) with statistical information that I need to transfer to
mysql database for processing and reporting. That application constantly
keeps connection to the last mdb file until week changes, but I need
that data from access at least every hour. I'm using mdbtools and my own
perl application to migrate data to mysql, before that I copy that last
mdb file together with ldb one to different location, not accessible for
that application. Somehow MS made database corrupted until someone uses
it, so is it possible to drop that connection or anything...? I can
retrieve db schema from access database but not a single record,
although if I open it with MS Access - I can see all data.

Thanks in advance

Mindaugas K.

Re: [mdb-dev] segmentation fault with mdb-export (built from CVS today)

[Jeff S. <why...@ya...>]

--- trek DC <tr...@ho...> wrote:
> Row 15 bytes 2399 to -30253 [lookup]
> bitmask_sz 2
> row_var_cols -1
> row_fixed_cols 11
> 
> the only pattern I see is that [delflag] is not set for Row 15

There was a bug (in code I recently submitted) that caused row length to be miscalculated
when the lookup and/or delete flags were present.  I have corrected this in cvs.

 -- Jeff Smith

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[mdb-dev] latest CVS version crashes

[Horst K. <md...@kn...>]

Hi,

installation of the latest CVS version (March 22) works ok, but starting any 
application I get a memory allocation error.


I use Suse 9.2

The following way I did the installation:
./autogen.sh
./configure
make
make install


valgrind delivers the following output

valgrind: Use --help for more information.
horst@notebookhorst:~/mdbtools> valgrind --tool=addrcheck mdb-tables
 ~/NORDWIND.MDB
==8408== Addrcheck, a fine-grained address checker for x86-linux.
==8408== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et
 al.
==8408== Using valgrind-2.2.0, a program supervision framework for x
86-linux.
==8408== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et
 al.
==8408== For more details, rerun with: -v
==8408==
==8408== Invalid read of size 1
==8408==    at 0x3416F810: mdb_crack_row (write.c:139)
==8408==    by 0x3416B732: mdb_read_row (data.c:263)
==8408==    by 0x3416B9FF: mdb_fetch_row (data.c:397)
==8408==    by 0x341689D6: mdb_read_catalog (catalog.c:96)
==8408==  Address 0x3337ABA9 is not stack'd, malloc'd or (recently)
free'd
==8408==
==8408== Process terminating with default action of signal 11 (SIGSE
GV)
==8408==  Access not within mapped region at address 0x3337ABA9
==8408==    at 0x3416F810: mdb_crack_row (write.c:139)
==8408==    by 0x3416B732: mdb_read_row (data.c:263)
==8408==    by 0x3416B9FF: mdb_fetch_row (data.c:397)
==8408==    by 0x341689D6: mdb_read_catalog (catalog.c:96)
==8408==
==8408== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==8408== malloc/free: in use at exit: 110078 bytes in 137 blocks.
==8408== malloc/free: 824 allocs, 687 frees, 1500936 bytes allocated.
==8408== For a detailed leak analysis,  rerun with: --leak-check=yes
==8408== For counts of detected errors, rerun with: -v
Speicherzugriffsfehler

RE: [mdb-dev] Problems with mdbtools handling large numbers

[Jeff S. <why...@ya...>]

I could not reproduce this problem.  Does compacting this in Access correct this problem?
 If not, then my suggestion is to delete all other tables, compact the database, and send
the file to me (not the list) to analyze.  If this is not possible, you may have to turn
debugging options on and narrow it down yourself.

 -- Jeff Smith


--- "Seuffert, Peter J." <pet...@ng...> wrote:

> Thank you for your swift reply Jeff.  Unfortunately, I have found another problem that
> may or may not be related.
> 
> I've attached two files that demonstrate what I'm seeing, but in essence, if the table
> consists of only numbers, there appear to be data loss issues.  The db I'm using is a
> large relational db, and most of the tables start with a three column key consisting of
> 2 strings and an integer value.  Using the mdb-export utility, I have verified that
> these tables are being read in without problem.  There is at least one table, however,
> that consists of numerous rows containing four columns, and using the mdb-export tool,
> I can see that I'm losing data in the export functionality.  More specifically, the
> rows that end in zero seem to be exported fine, while all those that don't come across
> as just commas.  For example, using Access to export the data into csv files, one
> excerpt shows:
> 
> 2,39,340.00,0.00
> 2,40,350.00,0.00
> 3,1,0.00,3.00
> 3,2,45.00,2.00
> 3,3,90.00,0.00
> 
> while the mdb-export utility leaves the same area looking like:
> 
> 2,39,340,0
> 2,40,350,0
> ,,,
> ,,,
> 3,3,90,0
> 
> The .csv file attached is from mdb-export, while the .txt is from Access.  Any help
> would be greatly appreciated.
> 
> Thanks,
> Pete
> 
> Peter Seuffert II
> Northrop Grumman Corporation
> 
> 
> -----Original Message-----
> From: Jeff Smith [mailto:why...@ya...]
> Sent: Saturday, March 19, 2005 9:56 AM
> To: Seuffert, Peter J.; mdb...@li...
> Subject: Re: [mdb-dev] Problems with mdbtools handling large numbers
> 
> 
> --- "Seuffert, Peter J." <pet...@ng...> wrote:
> > I'm trying to use mdbtools to read an access97 db on a Fedora Core 2 linux box.  Its
> > working fantastically, except for one issue with large numbers.  In Access, I can see
> > the numbers in one column increase up past 100,000, but in a while mdb_fetch_row()
> > loop, the last valid value my program receives is 100,000.  The next number in the db
> > should be 125,000 but the value being returned by mdbtools is truncated to 125.  The
> > mdb-export utility is verifying that my program isn't doing anything quirky with the
> > return.
> 
> Peter,
>   I have isolated the problem and it is now fixed in cvs.  Trailing zeros after a
> decimal
> point were supposed to be trimmed, but the trailing-zero trimming was also occurring on
> numbers without a decimal point.  100000 worked only because of a quirk that caused it
> to
> have an intermediate value of "100000.0".  I have corrected this as well, though I
> doubt
> many people will notice as its effects are more subtle.
> 
>   Thank you for your report.
> 
>  -- Jeff Smith
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/ 
> > 0,1,0.00,0.00
> 0,2,90.00,0.00
> 0,3,180.00,0.00
> 0,4,270.00,0.00
> 1,1,0.00,0.00
> 1,2,45.00,0.00
> 1,3,90.00,0.00
> 1,4,135.00,0.00
> 1,5,180.00,0.00
> 1,6,225.00,0.00
> 1,7,270.00,0.00
> 1,8,315.00,0.00
> 2,1,0.00,0.00
> 2,2,10.00,0.00
> 2,3,20.00,0.00
> 2,4,30.00,0.00
> 2,5,40.00,0.00
> 2,6,45.00,0.00
> 2,7,50.00,0.00
> 2,8,60.00,0.00
> 2,9,70.00,0.00
> 2,10,80.00,0.00
> 2,11,90.00,0.00
> 2,12,100.00,0.00
> 2,13,110.00,0.00
> 2,14,120.00,0.00
> 2,15,130.00,0.00
> 2,16,135.00,0.00
> 2,17,140.00,0.00
> 2,18,150.00,0.00
> 2,19,160.00,0.00
> 2,20,170.00,0.00
> 2,21,180.00,0.00
> 2,22,190.00,0.00
> 2,23,200.00,0.00
> 2,24,210.00,0.00
> 2,25,220.00,0.00
> 2,26,225.00,0.00
> 2,27,230.00,0.00
> 2,28,240.00,0.00
> 2,29,250.00,0.00
> 2,30,260.00,0.00
> 2,31,270.00,0.00
> 2,32,280.00,0.00
> 2,33,290.00,0.00
> 2,34,300.00,0.00
> 2,35,310.00,0.00
> 2,36,315.00,0.00
> 2,37,320.00,0.00
> 2,38,330.00,0.00
> 2,39,340.00,0.00
> 2,40,350.00,0.00
> 3,1,0.00,3.00
> 3,2,45.00,2.00
> 3,3,90.00,0.00
> 3,4,135.00,0.00
> 3,5,180.00,2.00
> 3,6,225.00,0.00
> 3,7,270.00,0.00
> 3,8,315.00,2.00
> 4,1,0.00,2.00
> 4,2,45.00,1.00
> 4,3,90.00,0.00
> 4,4,135.00,0.00
> 4,5,180.00,2.00
> 4,6,225.00,0.00
> 4,7,270.00,0.00
> 4,8,315.00,1.00
> 5,1,0.00,3.00
> 5,2,45.00,2.00
> 5,3,90.00,0.00
> 5,4,135.00,1.00
> 5,5,180.00,3.00
> 5,6,225.00,1.00
> 5,7,270.00,0.00
> 5,8,315.00,2.00
> 6,1,0.00,3.00
> 6,2,45.00,1.00
> 6,3,90.00,0.00
> 6,4,135.00,1.00
> 6,5,180.00,3.00
> 6,6,225.00,1.00
> 6,7,270.00,0.00
> 6,8,315.00,1.00
> 7,1,0.00,6.00
> 7,2,45.00,2.00
> 7,3,90.00,0.00
> 7,4,135.00,2.00
> 7,5,180.00,6.00
> 7,6,225.00,2.00
> 7,7,270.00,0.00
> 7,8,315.00,2.00
> 8,1,0.00,0.00
> 8,2,45.00,2.00
> 8,3,90.00,6.00
> 8,4,135.00,2.00
> 8,5,180.00,0.00
> 8,6,225.00,2.00
> 8,7,270.00,6.00
> 8,8,315.00,2.00
> 9,1,0.00,6.00
> 9,2,45.00,4.00
> 9,3,90.00,3.00
> 9,4,135.00,4.00
> 9,5,180.00,6.00
> 9,6,225.00,0.00
> 9,7,270.00,0.00
> 9,8,315.00,0.00
> 10,1,0.00,6.00
> 10,2,45.00,0.00
> 10,3,90.00,0.00
> 10,4,135.00,0.00
> 10,5,180.00,6.00
> 10,6,225.00,4.00
> 10,7,270.00,3.00
> 10,8,315.00,4.00
> 11,1,0.00,15.00
> 11,2,45.00,10.00
> 11,3,90.00,0.00
> 11,4,135.00,3.00
> 11,5,180.00,6.00
> 11,6,225.00,3.00
> 11,7,270.00,0.00
> 11,8,315.00,10.00
> 12,1,0.00,6.00
> 12,2,45.00,4.00
> 12,3,90.00,3.00
> 12,4,135.00,4.00
> 12,5,180.00,3.00
> 12,6,225.00,0.00
> 12,7,270.00,0.00
> 12,8,315.00,0.00
> 13,1,0.00,2.00
> 13,2,90.00,0.00
> 13,3,180.00,6.00
> 13,4,270.00,0.00
> 14,1,0.00,6.00
> 14,2,90.00,3.00
> 14,3,180.00,0.00
> 14,4,270.00,3.00
> 15,1,0.00,3.00
> 15,2,45.00,1.00
> 15,3,90.00,0.00
> 15,4,135.00,3.00
> 15,5,180.00,1.00
> 15,6,225.00,1.00
> 15,7,270.00,0.00
> 15,8,315.00,1.00
> 16,1,0.00,6.00
> 16,2,45.00,2.00
> 16,3,90.00,6.00
> 16,4,135.00,2.00
> 16,5,180.00,0.00
> 16,6,225.00,2.00
> 16,7,270.00,6.00
> 16,8,315.00,2.00
> 17,1,0.00,2.00
> 17,2,90.00,0.00
> 17,3,180.00,6.00
> 17,4,270.00,9.00
> 18,1,0.00,6.00
> 18,2,90.00,3.00
> 18,3,180.00,0.00
> 18,4,270.00,5.00
> 19,1,0.00,2.00
> 19,2,90.00,0.00
> 19,3,180.00,6.00
> 19,4,270.00,4.00
> 20,1,0.00,6.00
> 20,2,90.00,2.00
> 20,3,180.00,0.00
> 20,4,270.00,2.00
> 21,1,0.00,0.00
> 21,2,45.00,0.00
> 21,3,90.00,0.00
> 21,4,135.00,2.00
> 21,5,180.00,6.00
> 21,6,225.00,2.00
> 21,7,270.00,0.00
> 21,8,315.00,0.00
> 22,1,0.00,0.00
> 22,2,90.00,0.00
> 22,3,180.00,6.00
> 22,4,270.00,0.00
> 23,1,0.00,0.00
> 23,2,90.00,0.00
> 23,3,180.00,0.00
> 23,4,270.00,0.00
> 24,1,0.00,3.00
> 24,2,45.00,2.00
> 24,3,90.00,0.00
> 24,4,135.00,1.00
> 24,5,180.00,3.00
> 24,6,225.00,12.00
> 24,7,270.00,0.00
> 24,8,315.00,2.00
> 25,1,0.00,15.00
> 25,2,45.00,6.00
> 25,3,90.00,3.00
> 25,4,135.00,0.00
> 25,5,180.00,0.00
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RE: [mdb-dev] Problems with mdbtools handling large numbers

[Seuffert, P. J. <pet...@ng...>]

Thank you for your swift reply Jeff.  Unfortunately, I have found =
another problem that may or may not be related.

I've attached two files that demonstrate what I'm seeing, but in =
essence, if the table consists of only numbers, there appear to be data =
loss issues.  The db I'm using is a large relational db, and most of the =
tables start with a three column key consisting of 2 strings and an =
integer value.  Using the mdb-export utility, I have verified that these =
tables are being read in without problem.  There is at least one table, =
however, that consists of numerous rows containing four columns, and =
using the mdb-export tool, I can see that I'm losing data in the export =
functionality.  More specifically, the rows that end in zero seem to be =
exported fine, while all those that don't come across as just commas.  =
For example, using Access to export the data into csv files, one excerpt =
shows:

2,39,340.00,0.00
2,40,350.00,0.00
3,1,0.00,3.00
3,2,45.00,2.00
3,3,90.00,0.00

while the mdb-export utility leaves the same area looking like:

2,39,340,0
2,40,350,0
,,,
,,,
3,3,90,0

The .csv file attached is from mdb-export, while the .txt is from =
Access.  Any help would be greatly appreciated.

Thanks,
Pete

Peter Seuffert II
Northrop Grumman Corporation


-----Original Message-----
From: Jeff Smith [mailto:why...@ya...]
Sent: Saturday, March 19, 2005 9:56 AM
To: Seuffert, Peter J.; mdb...@li...
Subject: Re: [mdb-dev] Problems with mdbtools handling large numbers


--- "Seuffert, Peter J." <pet...@ng...> wrote:
> I'm trying to use mdbtools to read an access97 db on a Fedora Core 2 =
linux box.  Its
> working fantastically, except for one issue with large numbers.  In =
Access, I can see
> the numbers in one column increase up past 100,000, but in a while =
mdb_fetch_row()
> loop, the last valid value my program receives is 100,000.  The next =
number in the db
> should be 125,000 but the value being returned by mdbtools is =
truncated to 125.  The
> mdb-export utility is verifying that my program isn't doing anything =
quirky with the
> return.

Peter,
  I have isolated the problem and it is now fixed in cvs.  Trailing =
zeros after a decimal
point were supposed to be trimmed, but the trailing-zero trimming was =
also occurring on
numbers without a decimal point.  100000 worked only because of a quirk =
that caused it to
have an intermediate value of "100000.0".  I have corrected this as =
well, though I doubt
many people will notice as its effects are more subtle.

  Thank you for your report.

 -- Jeff Smith


	=09
__________________________________=20
Do you Yahoo!?=20
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/=20

[mdb-dev] segmentation fault with mdb-export (built from CVS today)

[trek D. <tr...@ho...>]

Exporting a table from a JET4 mdb with the latest CVS as of 2005-03-21:

Program received signal SIGSEGV, Segmentation fault.
0x00eca271 in mdb_crack_row (table=0x9422ef8, row_start=2399, 
row_end=-1074284864, fields=0xbff7b6c0) at write.c:226
226                     fields[i].is_null = nullmask[byte_num] & (1 << 
bit_num) ? 0 : 1;
(gdb) backtrace
#0  0x00eca271 in mdb_crack_row (table=0x9422ef8, row_start=2399, 
row_end=-1074284864, fields=0xbff7b6c0) at write.c:226
#1  0x00ec7653 in mdb_read_row (table=0x9422ef8, row=15) at data.c:263
#2  0x00ec78a7 in mdb_fetch_row (table=0x9422ef8) at data.c:397
#3  0x08048e9e in main (argc=155336168, argv=0xbff7cfe4) at mdb-export.c:186

I rebuilt setting MDB_DEBUG to 1 in mdbtools.h and set MDBOPTS to debug_all
Row 12 bytes 2615 to -46538 [lookup] [delflag]
Row 13 bytes 2615 to -46538 [lookup] [delflag]
Row 14 bytes 2516 to 2614
sarg test passed row 14
bitmask_sz 2
row_var_cols 6
row_fixed_cols 4

Row 15 bytes 2399 to -30253 [lookup]
bitmask_sz 2
row_var_cols -1
row_fixed_cols 11

the only pattern I see is that [delflag] is not set for Row 15

Note:  the seg fault didn't occur using the 2004-06-18 version (although 
text was truncated in memo fields)

[mdb-dev] Java-Tools: Exception on connection

[Johannes E. <web...@fb...>]

Hi everyone.

I am trying to use the Java port of this lib in order to access a 
database on my Macintosh.

I get the following exception:

java.lang.ArrayIndexOutOfBoundsException: 168234952
	at mdbtools.libmdb.Data.mdb_read_row(Data.java:252)
	at mdbtools.libmdb.Data.mdb_fetch_row(Data.java:91)
	at mdbtools.libmdb.Catalog.mdb_read_catalog(Catalog.java:41)
	at mdbtools.jdbc2.MDBConnection.<init>(MDBConnection.java:23)
	at mdbtools.jdbc2.Driver.connect(Driver.java:45)
	at java.sql.DriverManager.getConnection(DriverManager.java:512)
	at java.sql.DriverManager.getConnection(DriverManager.java:193)
	at TestMDB.main(TestMDB.java:29)


with the following code:

try {
     Class.forName("mdbtools.jdbc.Driver");

     Connection conn = DriverManager.getConnection("jdbc:mdbtools:" + 
FILENAME);
     ResultSet rset = conn.getMetaData().getTables(null,null,null,null);

     while (rset.next())
         System.out.println(rset.getString("table_name"));

     rset.close();
     conn.close();
} catch (Exception e) {
     e.printStackTrace();
}

This testcode is mainly copy-paste from the examples packages. The 
exception is thrown in the DriverManager.getConnection() line.
I had this problem with any version, I've tried, the release version, 
the r2-version and even with the current cvs version.

If there is anything I can do or test for you, just ask ;)

Kind Regards
Johannes

[mdb-dev] There are always problems to work whith JET3

[Emilio P. <ep....@ce...>]

I try since few days to work on databases in JET3 format. The result is always 
a segmentation fault; it seems to work only the db-ver utility.

I saw the mail from Gordon MacQueen and the answare by Jeff Smith on 
3-11-2005; and hoped there was the solution, but it seems no.

Debugging the sources I find that the problem arises in the function 
mdb_read_row: here the call to mdb_find_row(mdb, row, &row_start, &row_size) 
puts a negative value into row_size at the end of the database.

I jump over the problem modifying data.c as follows
  
 ..........
   255                  lookupflag ? "[lookup]" : "",
   256                  delflag ? "[delflag]" : "");
   257  #endif
   258          /** Patch by Cesip */     
   259          if ( row_size < 0 )
   260                  return 0;
   261          /** End patch **/
................

Is this solution valid in every case ? or does exist a better generalized 
one ?

Thank you for attention.

Emilio Primi
Cesip srl
ep....@ce...

Re: [mdb-dev] Problems with mdbtools handling large numbers

[Jeff S. <why...@ya...>]

--- "Seuffert, Peter J." <pet...@ng...> wrote:
> I'm trying to use mdbtools to read an access97 db on a Fedora Core 2 linux box.  Its
> working fantastically, except for one issue with large numbers.  In Access, I can see
> the numbers in one column increase up past 100,000, but in a while mdb_fetch_row()
> loop, the last valid value my program receives is 100,000.  The next number in the db
> should be 125,000 but the value being returned by mdbtools is truncated to 125.  The
> mdb-export utility is verifying that my program isn't doing anything quirky with the
> return.

Peter,
  I have isolated the problem and it is now fixed in cvs.  Trailing zeros after a decimal
point were supposed to be trimmed, but the trailing-zero trimming was also occurring on
numbers without a decimal point.  100000 worked only because of a quirk that caused it to
have an intermediate value of "100000.0".  I have corrected this as well, though I doubt
many people will notice as its effects are more subtle.

  Thank you for your report.

 -- Jeff Smith


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

[mdb-dev] Problems with mdbtools handling large numbers

[Seuffert, P. J. <pet...@ng...>]

Greetings,
	I'm trying to use mdbtools to read an access97 db on a Fedora Core 2 =
linux box.  Its working fantastically, except for one issue with large =
numbers.  In Access, I can see the numbers in one column increase up =
past 100,000, but in a while mdb_fetch_row() loop, the last valid value =
my program receives is 100,000.  The next number in the db should be =
125,000 but the value being returned by mdbtools is truncated to 125.  =
The mdb-export utility is verifying that my program isn't doing anything =
quirky with the return.
	I've searched through the email Archives, and have seen others are =
having the same problem with large number truncation.  Has there been a =
patch for this yet?

Thanks,
Pete

Peter Seuffert II
Northrop Grumman Corporation

Re: [mdb-dev] Crash in mdb-import

[<bo...@ma...>]

Thanks, but i think there were no insert/remove when i created the=20
file. I'll double check. Thanks.

Regards,
Mikl=F3s
On Mar 16, 2005, at 2:10 PM, Sam Moffatt wrote:

> What could be causing the result to be 21 is if rows have been deleted
> from the table and rows added afterwards. 21 could be the index of th
> e last row. I might be wrong, but it would appear to make sense.
> Someone with a bit more time might be able to help,
>
> Sam
>
> On Wed, 16 Mar 2005 08:17:09 +0100, Mikl=F3s Fazekas <bo...@ma...>=20
> wrote:
>> I've tried to use mdb-import for a simple jet4 db.
>> The result was a crash in the following code:
>>
>> (The sample file can be found attached to the bug:
>> http://sourceforge.net/tracker/index.php?
>> func=3Ddetail&aid=3D1163895&group_id=3D2294&atid=3D102294
>> )
>>
>>   } else { /* is not a temp table */
>>         new_pg =3D mdb_new_data_pg(entry);
>>
>>          num_rows =3D mdb_pg_get_int16(mdb, fmt->row_count_offset);
>>          pos =3D fmt->pg_size;
>>
>>         /* copy existing rows */
>>         for (i=3D0;i<num_rows;i++) {
>>                 mdb_find_row(mdb, i, &row_start, &row_size);
>>                 pos -=3D row_size;
>>
>>                 memcpy(&new_pg[pos], &mdb->pg_buf[row_start],=20
>> row_size);
>> ^^^^^^^^^^^^^-crash for i =3D=3D 5
>>                 _mdb_put_int16(new_pg, (fmt->row_count_offset + 2) +=20=

>> (i*2), pos);
>>          }
>>   }
>>
>> Any hints?!
>> For me the num_rows seems to be too large (it's 21 while the table =
has
>> only 4 rows), but i might be completly wrong.
>> [ And setting the num_rows to 4 solved the crash but the result was
>> still a bit bogus... ]
>>
>> Regards,
>> Mikl=F3s
>>
>>

Re: [mdb-dev] Crash in mdb-import

[Sam M. <pa...@gm...>]

What could be causing the result to be 21 is if rows have been deleted
from the table and rows added afterwards. 21 could be the index of th
e last row. I might be wrong, but it would appear to make sense.
Someone with a bit more time might be able to help,

Sam

On Wed, 16 Mar 2005 08:17:09 +0100, Mikl=F3s Fazekas <bo...@ma...> wrote:
> I've tried to use mdb-import for a simple jet4 db.
> The result was a crash in the following code:
>=20
> (The sample file can be found attached to the bug:
> http://sourceforge.net/tracker/index.php?
> func=3Ddetail&aid=3D1163895&group_id=3D2294&atid=3D102294
> )
>=20
>   } else { /* is not a temp table */
>         new_pg =3D mdb_new_data_pg(entry);
>=20
>          num_rows =3D mdb_pg_get_int16(mdb, fmt->row_count_offset);
>          pos =3D fmt->pg_size;
>=20
>         /* copy existing rows */
>         for (i=3D0;i<num_rows;i++) {
>                 mdb_find_row(mdb, i, &row_start, &row_size);
>                 pos -=3D row_size;
>=20
>                 memcpy(&new_pg[pos], &mdb->pg_buf[row_start], row_size);
> ^^^^^^^^^^^^^-crash for i =3D=3D 5
>                 _mdb_put_int16(new_pg, (fmt->row_count_offset + 2) + (i*2=
), pos);
>          }
>   }
>=20
> Any hints?!
> For me the num_rows seems to be too large (it's 21 while the table has
> only 4 rows), but i might be completly wrong.
> [ And setting the num_rows to 4 solved the crash but the result was
> still a bit bogus... ]
>=20
> Regards,
> Mikl=F3s
>=20
>

Re: [mdb-dev] Crash in mdb-import

[Brian B. <bri...@gm...>]

The mdb-import functionality is not fully implement yet.  It is very
much a work in progress, so even if it didn't crash it probably
wouldn't work. :-/

Brian


On Wed, 16 Mar 2005 08:17:09 +0100, Mikl=F3s Fazekas <bo...@ma...> wrote:
> I've tried to use mdb-import for a simple jet4 db.
> The result was a crash in the following code:
>=20
> (The sample file can be found attached to the bug:
> http://sourceforge.net/tracker/index.php?
> func=3Ddetail&aid=3D1163895&group_id=3D2294&atid=3D102294
> )
>=20
>   } else { /* is not a temp table */
>         new_pg =3D mdb_new_data_pg(entry);
>=20
>          num_rows =3D mdb_pg_get_int16(mdb, fmt->row_count_offset);
>          pos =3D fmt->pg_size;
>=20
>         /* copy existing rows */
>         for (i=3D0;i<num_rows;i++) {
>                 mdb_find_row(mdb, i, &row_start, &row_size);
>                 pos -=3D row_size;
>=20
>                 memcpy(&new_pg[pos], &mdb->pg_buf[row_start], row_size);
> ^^^^^^^^^^^^^-crash for i =3D=3D 5
>                 _mdb_put_int16(new_pg, (fmt->row_count_offset + 2) + (i*2=
), pos);
>          }
>   }
>=20
> Any hints?!
> For me the num_rows seems to be too large (it's 21 while the table has
> only 4 rows), but i might be completly wrong.
> [ And setting the num_rows to 4 solved the crash but the result was
> still a bit bogus... ]
>=20
> Regards,
> Mikl=F3s
>=20
>

[mdb-dev] Crash in mdb-import

[<bo...@ma...>]

I've tried to use mdb-import for a simple jet4 db.
The result was a crash in the following code:

(The sample file can be found attached to the bug:
http://sourceforge.net/tracker/index.php?=20
func=3Ddetail&aid=3D1163895&group_id=3D2294&atid=3D102294
)


  } else { /* is not a temp table */
  	new_pg =3D mdb_new_data_pg(entry);

	 num_rows =3D mdb_pg_get_int16(mdb, fmt->row_count_offset);
	 pos =3D fmt->pg_size;

  	/* copy existing rows */
  	for (i=3D0;i<num_rows;i++) {
		mdb_find_row(mdb, i, &row_start, &row_size);
  		pos -=3D row_size;

  		memcpy(&new_pg[pos], &mdb->pg_buf[row_start], row_size);
^^^^^^^^^^^^^-crash for i =3D=3D 5
  		_mdb_put_int16(new_pg, (fmt->row_count_offset + 2) + =
(i*2), pos);
	 }
  }

Any hints?!
For me the num_rows seems to be too large (it's 21 while the table has =20=

only 4 rows), but i might be completly wrong.
[ And setting the num_rows to 4 solved the crash but the result was =20
still a bit bogus... ]

Regards,
Mikl=F3s

Re: [mdb-dev] Problem connecting to cvs server

[Sam M. <pa...@gm...>]

This is a sourceforge issue unrelated to MDB-Tools. Read the list
archives for more information or check out a previous CVS outage on
projects starting with M, etc,

Sam


On Mon, 14 Mar 2005 15:18:25 -0000, Gordon MacQueen
<go...@co...> wrote:
> I can't seem to connect to the CVS server for the latest updates.
> Here is a copy of the output:
> 
> -bash-3.00$ cvs -d:pserver:ano...@cv...:/cvsroot/mdbtools
> login
> Logging in to :pserver:ano...@cv...:2401/cvsroot/mdbtools
> CVS password:
> cvs [login aborted]: unrecognized auth response from cvs.sourceforge.net: M
> PserverBackend::PserverBackend() Connect (Connection refused)
> 
> I have tried several passwords, including leaving the field blank
> altogether, each time I get the same error message returned.
> 
> Any help would be greatly appreciated,
> Gordon MacQueen
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
>