mdbtools-dev

Re: [mdb-dev] Python bindings / Hello from new Gentoo maintainer

[Nirgal <con...@ni...>]

On Thursday 23 May 2013 22:46:01 Chris Kerr wrote:
> Since there is currently no maintainer for mdbtools on the Gentoo Linux 
> distribution, I wrote my own ebuild for mdbtools-0.7 and have volunteered 
> to be the mdbtools maintainer from now on. Hopefully mdbtools-0.7 should 
> be in the main Portage tree in the next few days. I've signed up to this 
> mailing list and am following mdbtools on GitHub - please let me know if 
> there is any other source of info I should be following.

Hi Chris

I'm using Debian, so I take extra care of that distro.

You might want to include a few hotfixes patches:
http://patch-tracker.debian.org/patch/series/view/mdbtools/0.7-2/gmdb2_double_free
http://patch-tracker.debian.org/patch/series/view/mdbtools/0.7-2/binaries_to_string

Additionnaly, I wrote a few bash-completion snipet a packager might like:
http://sources.debian.net/src/mdbtools/0.7-2/debian/mdbtools.bash-completion
http://sources.debian.net/src/mdbtools/0.7-2/debian/mdbtools-gmdb.bash-completion
I plan to merge these in the main github repo. Any idea where it should go?
In a dist/ directory maybe?


Cheers!

Re: [mdb-dev] Problem connecting to Access Database on Windows Server from 32 bit Linux

[Nirgal <con...@ni...>]

On Friday 03 May 2013 16:42:02 Alexander Lehner wrote:
> I understand what the error message says and am wondering how such code 
> could become an official release. As far as I understand, such 
> construction never will compile.

Actually, it depends on the compiler version.
See http://gcc.gnu.org/ml/gcc-bugs/2004-12/msg00415.html

Re: [mdb-dev] Problem connecting to Access Database on Windows Server from 32 bit Linux

[Nirgal <con...@ni...>]

> backend.c:31:20: error: static declaration of 'mdb_backends' follows
> non-static declaration
> ../../include/mdbtools.h:150:20: note: previous declaration of
> 'mdb_backends' was here
> make[2]: *** [backend.lo] Error 1
> 
> Could anyone offer any suggestions?

Fixed since version 0.7

[mdb-dev] Problems to connect to mdb-file with unixODBC and mdbtools driver in Perl

[Sebastian R. <sn...@lm...>]

Hi,
In past I have used mdb-tools- command line utils for reading data from 
an mdb-file. Now I try to write an perl script by using DBD::ODBC and 
libmdbodbc- driver.
But I can connect to mdb-file, if I put the database information in my 
"~/.odbc.ini"- file ,only!
If I use this "ini-file"- input with this connect line:
my $dbh = DBI->connect('DBI:ODBC:MDBDSN', $user, $pass, { RaiseError => 1});
in my Perl script, I can connect to the file.
If I try to connect to the mdb-file with:
my $dbh = 
DBI->connect('DBI:ODBC:DRIVER={MDBToolsODBC};database=/mnt/lvm/SNR_Soft/Kivitendo_Import/in/kramp/Kramp.dat' 
$user, $pass, { RaiseError => 1});
it fails with this error:
DBI 
connect('DRIVER={MDBToolsODBC};database=/mnt/lvm/SNR_Soft/Kivitendo_Import/in/kramp/Kramp.dat','',...) 
failed: [unixODBC]Could not find DSN in connect string (SQL-08001)

This is my odbc.ini:
----------
[MDBDSN]
Description = MDBDSN
Driver = MDBToolsODBC
Database = /mnt/lvm/SNR_Soft/Kivitendo_Import/in/kramp/Kramp.dat
Servername = localhost
Port = 5432
----------

So why it fails without the ini file? The ini-file is no solution, 
because I have to be able to put in different files!

Next problem is, that "mdb-tables" shows this tables contained in mdb- file:
------------------------------------------------
mdb-tables in/kramp/Kramp.dat
KATALOG Pricelist RC_01012011 Schnelldreher Stand T_Rabatt_codes 
T_RC_neu T_upd_RC WEBLINKS
------------------------------------------------
But, if I read out the tables with "my @tables = $dbh->tables();" (with 
connected data file by using odbc.ini), I get:
------------------------------------------------
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿMSysObjectsÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿMSysACEsÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿMSysQueriesÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿMSysRelationshipsÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿADD_CHCHF_DATAÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿDEL_DATAÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿKATALOGÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿMSysAccessObjectsÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿMSysIMEXColumnsÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿMSysIMEXSpecsÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿPricelistÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_upd_1050_Fÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_UPD_ARTIKEL_Berndÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_upd_manniÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_upd_Produktfÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_upd_Rabattcodeÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_upd_RCÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_upd_rc_01012011ÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_upd_schnelldreherÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_WEBLINKSÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿRC_01012011ÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿSchnelldreherÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿStandÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿT_Rabatt_codesÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿT_RC_neuÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿT_upd_RCÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿUPD_KATALOGÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿWEBLINKSÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿADD_AGEEUR_DATAÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿGET_DATA_AGEEUR_2007ÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿMSysAccessXMLÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_upd_Produktf_Ers_duÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.ÿÿÿÿÿÿQ_Update_Manni_Schneeÿÿÿÿÿÿ
------------------------------------------------

So, what is wrong? Can anyone help me? I have to read out more then 
250000 data lines for parsing. Using command line tools with an Perl 
script (sytem call inside the script), this process takes up to 4 days 
(2xQuad-core server, no lame duck!)! Not really usable. I hope with the 
mdbtools- driver it is much more faster.....


Is there any documentation about the libmdbodbc- driver available?

-- 
Kind regards

Sebastian Reinhardt

Re: [mdb-dev] Problem connecting to Access Database on Windows Server from 32 bit Linux

[Jean-Michel V. <con...@ni...>]

Hi

I still did not dig in your problem yet.

But you'd better take last version 0.7 from github:
https://github.com/brianb/mdbtools

Cheers

[mdb-dev] Python bindings / Hello from new Gentoo maintainer

[Chris K. <cha...@gm...>]

Hi there,

I'm a PhD student studying battery chemistry at the University of 
Cambridge, and I use mdbtools to extract data from the JetDB-based log 
format produced by Arbin Instruments battery test stations. (As is often 
the case with research hardware, the closed-source vendor-provided tool 
is buggy and runs only on Windows.)

Since there is currently no maintainer for mdbtools on the Gentoo Linux 
distribution, I wrote my own ebuild for mdbtools-0.7 and have volunteered 
to be the mdbtools maintainer from now on. Hopefully mdbtools-0.7 should 
be in the main Portage tree in the next few days. I've signed up to this 
mailing list and am following mdbtools on GitHub - please let me know if 
there is any other source of info I should be following.

I do almost all my data processing in Python; currently to extract the data I 
run mdb-export via subprocess.Popen and pass the INSERT statements 
directly into a temporary sqlite3 database, then query the sqlite3 
database for the data I need. Recently I've been having a quick look at the 
source code and I think I could knock together a Python binding that would 
support the very limited subset of operations I need relatively quickly. 
Searching online for Python MDB bindings seems only to give bindings for 
the Windows Jet DB API, but I thought I'd ask if anyone knows of anything 
I've missed, or has any suggestions on where to start. (I've only ever used 
F2Py to make bindings to Fortran code before, but I don't think it's the 
right solution for libmdb because of the heavy use of pointers.)

The format of the databases I'm using is basically a dozen or so relatively 
complicated tables with only a few rows each holding metadata and so on, 
plus one table holding the actual data (all columns are integers or floats). 
What I want to be able to do is read out the metadata tables into 
something similar to the sqlite3.Row object, and read the data table into a 
NumPy array.

Thanks for all the work you've done developing this code; it's been very 
helpful!

Chris

Re: [mdb-dev] Problem connecting to Access Database on Windows Server from 32 bit Linux

[Alexander L. <le...@ed...>]

On Sat, 4 May 2013, Andrew P Jones wrote:

> [...}
>
> I extracted the files from mdbtools-0.6pre1.tar.gz
>
> downloaded from http://sourceforge.net/projects/mdbtools/files/
>

OK, that's it. I can get the compile error with 6pre1 as well.

#####
Hack the source:

include/mdbtools.h, line 150, remove these lines:

/* hash to store registered backends */
extern GHashTable     *mdb_backends;

#####

There's no need to declare mdb_backends as global variable any longer, and 
in fact it isn't one.

In 0.5 there was a reference to mdb_backends from mem.c, but it's 
implementation now seems to have moved to backend.c, which is fine.


I'm just wondering why nobody else had this problem before?
I'm not a real mdbtools developer, just tracking this list. Is there a way 
to report this problem?
Won't actually dare to mess in the sources...

Alex.

Re: [mdb-dev] Problem connecting to Access Database on Windows Server from 32 bit Linux

[Andrew P J. <mdb...@an...>]

On Fri, 2013-05-03 at 18:42 +0200, Alexander Lehner wrote:
> >
> 
> What version of libmdb are you using?
> What says 'gcc --version'?

I extracted the files from mdbtools-0.6pre1.tar.gz

downloaded from http://sourceforge.net/projects/mdbtools/files/

$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

The packaged version of mdbtools currently installed and 'working' is

 $ aptitude show mdbtools
Package: mdbtools                        
State: installed
Automatically installed: no
Version: 0.5.99.0.6pre1.0.20051109-7.1
Priority: optional
Section: utils
Maintainer: Ubuntu Developers <ubu...@li...>
Uncompressed Size: 233 k
Depends: libc6 (>= 2.4), libglib2.0-0 (>= 2.12.0), libmdbtools (>=
0.5.99.0.6pre1.0.20051109), libreadline6 (>= 6.0)
Description: JET / MS Access database (MDB) tools
 These are various tools for manipulating JET / MS Access database (MDB)
files: 
 * utils     - provides command line utilities to list tables, export
schema, 
              and data, show file versions, and other useful stuff.
 * mdb-sql   - a command line SQL tool that allows one to type sql
queries and 
              get results.
 * odbc      - An ODBC driver for use with unixODBC driver manager.
Allows 
              one to use MDB files with PHP for example.
Homepage: http://sourceforge.net/projects/mdbtools/


> 
> I just downloaded mdbtools 0.5 release and 'make' was successful.
> 
> It seems that the line numbers compared to your error message do not 
> match to the sources I've got.
> 
> I understand what the error message says and am wondering how such code 
> could become an official release. As far as I understand, such 
> construction never will compile.
> 
> 
> Alex.
> 
I will download and try version 0.5 tomorrow.

Thanks for your help,

Andy

Re: [mdb-dev] Problem connecting to Access Database on Windows Server from 32 bit Linux

[Alexander L. <le...@ed...>]

On Fri, 3 May 2013, Andrew P Jones wrote:

> [...]
> I have a working installation of mdbtools installed from its package by
> apt on 32 bit Linux mint.
>
> However mdbtools tests for the presence of the database before opening
> it.  The way it tests is unreliable when using a Microsoft Access
> database hosted on a Windows server.
>
> The best information I can find to explain this unreliability is here:
>
> https://bugzilla.samba.org/show_bug.cgi?id=7707
> "Short answer: You need to recompile your test program with
>
>    -D_FILE_OFFSET_BITS=64
>
> What's happening is that glibc uses the stat64() system call to handle
> the stat, even with 32-bit non LFS programs. When it gets back a large
> inode number that doesn't fit in a 32-bit value, it generates EOVERFLOW
> in userspace and returns that to the program."
>
>
> ...And from Wikipedia
> https://en.wikipedia.org/wiki/Stat_%28system_call%29
> "The family of functions was extended to implement large file support.
> Functions named stat64(), lstat64() and fstat64() return attributes in a
> struct stat64 structure, which represents file sizes with a 64-bit type,
> allowing the functions to work on files 2 GiB and larger. When the
> _FILE_OFFSET_BITS macro is defined to 64, these 64-bit functions are
> available under the original names."
>
> I would like to be able to build the application from source so I can
> test if the above is true and if it breaks mdbtools for local files.
>
> Finally, if I run  stat <filename> from a terminal prompt the result
> displays with no apparent error and the inode number has 17 digits.  So
> I know the computer is capable of handling it but mdbtools is not.
>
>> The build failed due to the missing glib installation.
>>
> I thought I had glib installed correctly.  I was wrong.  After
> reinstalling it configure appears to work correctly.
>
> Now make fails...
>
> [...]
> make fails like this:
>
> gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include
> -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -g
> -O2 -DSQL -MT backend.lo -MD -MP -MF .deps/backend.Tpo -c backend.c
> -fPIC -DPIC -o .libs/backend.o
> backend.c:31:20: error: static declaration of 'mdb_backends' follows
> non-static declaration
> ../../include/mdbtools.h:150:20: note: previous declaration of
> 'mdb_backends' was here
> make[2]: *** [backend.lo] Error 1
> make[2]: Leaving directory
> `/home/jonesap/temp/mdbtools/mdbtools-0.6pre1/src/libmdb'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/home/jonesap/temp/mdbtools/mdbtools-0.6pre1/src'
> make: *** [all-recursive] Error 1
>
> Could anyone offer any suggestions?
>

What version of libmdb are you using?
What says 'gcc --version'?

I just downloaded mdbtools 0.5 release and 'make' was successful.

It seems that the line numbers compared to your error message do not 
match to the sources I've got.

I understand what the error message says and am wondering how such code 
could become an official release. As far as I understand, such 
construction never will compile.


Alex.

Re: [mdb-dev] Problem connecting to Access Database on Windows Server from 32 bit Linux

[Andrew P J. <mdb...@an...>]

On Thu, 2013-05-02 at 18:02 +0200, Alexander Lehner wrote:
> 
> On Thu, 2 May 2013, Andrew P Jones wrote:
> 
> > Apologies in advance: I haven't written any c for 10 years so although I
> > believe I have identified the bug I have not yet succeeded in building /
> > testing a fix.  Configure tells me I need glib2 but that is a different
> > issue.
> >
> > The meat of this mail is also on the linux mint forum as I am not sure
> > if the problem is packaging or mdbtools itself
> >
> > http://forums.linuxmint.com/viewtopic.php?f=47&t=132702
> >
> > The problem is that in src/libmdb/file.c  mdb_find_file() fails if
> > stat(Filename, &status) fails.
> >
> > Broadly speaking, the Windows server returns a 64 bit stat structure
> > which exceeds the length of the 32-bit stat structure allocated on the
> > linux box and causes stat() to fail.
> >
> > The above sentence was both inaccurate and garbled - a much better
> > explanation can be found here:
> >
> > https://bugzilla.samba.org/show_bug.cgi?id=7707#c1
> >
> > The above link recommends building with:
> >
> > -D_FILE_OFFSET_BITS=64
> >
> > I did wonder if it would be cleaner to change
> >   struct stat status;
> > to use a GStatBuf  and use the corresponding g_stat () call, but if I
> > have understood this page correctly...
> > https://developer.gnome.org/glib/2.35/glib-File-Utilities.html#GStatBuf
> > ... that will continue to use a 32 bit structure.
> >
> > Sorry if this reads like "Here's your problem - go fix it."  I have
> > tried several times to build the code downloaded from sourceforge
> > without success.  If anyone has seen and worked around the error below
> > and can tell me how to without breaking the linux Mint box which I am
> > accessing remotely I will gladly experiment further.
> >
> > checking for GLIB - version >= 2.0.0... no
> > *** Could not run GLIB test program, checking why...
> > *** The test program failed to compile or link. See the file config.log
> > for the
> > *** exact error that occured. This usually means GLIB is incorrectly
> > installed.
> >
> > glib 2.0 is required by MDB Tools.
> > It can be downloaded at www.gtk.org.
> >
> 
> Not quite sure whether I understand your problems:
> 
> You seem to have a working binary of libmdb but that one only supports 32 
> bit.
> You want to build it on your own for 64 bit.
> 
I have a working installation of mdbtools installed from its package by
apt on 32 bit Linux mint.

However mdbtools tests for the presence of the database before opening
it.  The way it tests is unreliable when using a Microsoft Access
database hosted on a Windows server.

The best information I can find to explain this unreliability is here:

https://bugzilla.samba.org/show_bug.cgi?id=7707
"Short answer: You need to recompile your test program with 

    -D_FILE_OFFSET_BITS=64

What's happening is that glibc uses the stat64() system call to handle
the stat, even with 32-bit non LFS programs. When it gets back a large
inode number that doesn't fit in a 32-bit value, it generates EOVERFLOW
in userspace and returns that to the program."


...And from Wikipedia
https://en.wikipedia.org/wiki/Stat_%28system_call%29
"The family of functions was extended to implement large file support.
Functions named stat64(), lstat64() and fstat64() return attributes in a
struct stat64 structure, which represents file sizes with a 64-bit type,
allowing the functions to work on files 2 GiB and larger. When the
_FILE_OFFSET_BITS macro is defined to 64, these 64-bit functions are
available under the original names."

I would like to be able to build the application from source so I can
test if the above is true and if it breaks mdbtools for local files.

Finally, if I run  stat <filename> from a terminal prompt the result
displays with no apparent error and the inode number has 17 digits.  So
I know the computer is capable of handling it but mdbtools is not.

> The build failed due to the missing glib installation.
> 
I thought I had glib installed correctly.  I was wrong.  After
reinstalling it configure appears to work correctly.

Now make fails...


> If you don't want to install glib (no idea what dependencies that pulls 
> in, but I guess you will not screw up your machine with that):
> 
> I had to build libmdb without glib for myself. What I did was replacing 
> the few glib functions beeing used by my own implementation.
> That were mostly some hash tables which I replaced by simply using the 
> STL, so it is no longer plain C code.
> 
> Also, that step requires some knowledge of autobuild, or you compile and 
> link the libmdb sources for yourself, which is not such big trouble.
> 
> If that helps, I can share my code.
> 
Thanks for your response, but all I want to do is to get a basic
standard version running.  

make fails like this:

 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include
-I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -g
-O2 -DSQL -MT backend.lo -MD -MP -MF .deps/backend.Tpo -c backend.c
-fPIC -DPIC -o .libs/backend.o
backend.c:31:20: error: static declaration of 'mdb_backends' follows
non-static declaration
../../include/mdbtools.h:150:20: note: previous declaration of
'mdb_backends' was here
make[2]: *** [backend.lo] Error 1
make[2]: Leaving directory
`/home/jonesap/temp/mdbtools/mdbtools-0.6pre1/src/libmdb'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/jonesap/temp/mdbtools/mdbtools-0.6pre1/src'
make: *** [all-recursive] Error 1

Could anyone offer any suggestions?

Thanks again
Andy

> Alex.

Re: [mdb-dev] Problem connecting to Access Database on Windows Server from 32 bit Linux

[Alexander L. <le...@ed...>]

On Thu, 2 May 2013, Andrew P Jones wrote:

> Apologies in advance: I haven't written any c for 10 years so although I
> believe I have identified the bug I have not yet succeeded in building /
> testing a fix.  Configure tells me I need glib2 but that is a different
> issue.
>
> The meat of this mail is also on the linux mint forum as I am not sure
> if the problem is packaging or mdbtools itself
>
> http://forums.linuxmint.com/viewtopic.php?f=47&t=132702
>
> The problem is that in src/libmdb/file.c  mdb_find_file() fails if
> stat(Filename, &status) fails.
>
> Broadly speaking, the Windows server returns a 64 bit stat structure
> which exceeds the length of the 32-bit stat structure allocated on the
> linux box and causes stat() to fail.
>
> The above sentence was both inaccurate and garbled - a much better
> explanation can be found here:
>
> https://bugzilla.samba.org/show_bug.cgi?id=7707#c1
>
> The above link recommends building with:
>
> -D_FILE_OFFSET_BITS=64
>
> I did wonder if it would be cleaner to change
>   struct stat status;
> to use a GStatBuf  and use the corresponding g_stat () call, but if I
> have understood this page correctly...
> https://developer.gnome.org/glib/2.35/glib-File-Utilities.html#GStatBuf
> ... that will continue to use a 32 bit structure.
>
> Sorry if this reads like "Here's your problem - go fix it."  I have
> tried several times to build the code downloaded from sourceforge
> without success.  If anyone has seen and worked around the error below
> and can tell me how to without breaking the linux Mint box which I am
> accessing remotely I will gladly experiment further.
>
> checking for GLIB - version >= 2.0.0... no
> *** Could not run GLIB test program, checking why...
> *** The test program failed to compile or link. See the file config.log
> for the
> *** exact error that occured. This usually means GLIB is incorrectly
> installed.
>
> glib 2.0 is required by MDB Tools.
> It can be downloaded at www.gtk.org.
>

Not quite sure whether I understand your problems:

You seem to have a working binary of libmdb but that one only supports 32 
bit.
You want to build it on your own for 64 bit.

The build failed due to the missing glib installation.

If you don't want to install glib (no idea what dependencies that pulls 
in, but I guess you will not screw up your machine with that):

I had to build libmdb without glib for myself. What I did was replacing 
the few glib functions beeing used by my own implementation.
That were mostly some hash tables which I replaced by simply using the 
STL, so it is no longer plain C code.

Also, that step requires some knowledge of autobuild, or you compile and 
link the libmdb sources for yourself, which is not such big trouble.

If that helps, I can share my code.

Alex.

[mdb-dev] Problem connecting to Access Database on Windows Server from 32 bit Linux

[Andrew P J. <mdb...@an...>]

Apologies in advance: I haven't written any c for 10 years so although I
believe I have identified the bug I have not yet succeeded in building /
testing a fix.  Configure tells me I need glib2 but that is a different
issue.

The meat of this mail is also on the linux mint forum as I am not sure
if the problem is packaging or mdbtools itself

http://forums.linuxmint.com/viewtopic.php?f=47&t=132702

The problem is that in src/libmdb/file.c  mdb_find_file() fails if
stat(Filename, &status) fails.

Broadly speaking, the Windows server returns a 64 bit stat structure
which exceeds the length of the 32-bit stat structure allocated on the
linux box and causes stat() to fail.

The above sentence was both inaccurate and garbled - a much better
explanation can be found here:

https://bugzilla.samba.org/show_bug.cgi?id=7707#c1

The above link recommends building with:

-D_FILE_OFFSET_BITS=64

I did wonder if it would be cleaner to change 
   struct stat status;
to use a GStatBuf  and use the corresponding g_stat () call, but if I
have understood this page correctly...
https://developer.gnome.org/glib/2.35/glib-File-Utilities.html#GStatBuf
... that will continue to use a 32 bit structure.

Sorry if this reads like "Here's your problem - go fix it."  I have
tried several times to build the code downloaded from sourceforge
without success.  If anyone has seen and worked around the error below
and can tell me how to without breaking the linux Mint box which I am
accessing remotely I will gladly experiment further.

checking for GLIB - version >= 2.0.0... no
*** Could not run GLIB test program, checking why...
*** The test program failed to compile or link. See the file config.log
for the
*** exact error that occured. This usually means GLIB is incorrectly
installed.

glib 2.0 is required by MDB Tools.
It can be downloaded at www.gtk.org.

Thanks and best regards,

Andrew Jones

BTW - Thanks for the great application.  Where do I send the postcard?

[mdb-dev] I do not have the file libmdbodbc.so

[HERNANDEZ H. A. <ahe...@ga...>]

Hello, 

I would like to have access to MS Access mdb files from Unix.

 

So, I have installed unixODBC and mdbtools-0.6pre1.tar.gz

 

The problem is that I do not have the file libmdbodbc.so. I have only
the next ones:

 

libmdbodbc -> libmdbodbc.0.0.0

libmdbodbc.0 -> libmdbodbc.0.0.0

libmdbodbc.0.0.0

libmdbodbc.a

libmdbodbc.la

 

I am a bit newbie in these things. Could you help me?

 

Best regards

[mdb-dev] Relationships not included in mdb-schema output

[Dale S. <dal...@sh...>]

(reposting from the right mail account)

Hi there, 

MS Access shows a number of relationships between tables in a (commercial)
mdb database, but there aren't any in the output from mdb-schema (not even
if I include --relations). I can recreate them manually, but thought this
would save the effort. Does it seem I may have misunderstood something?

P.S. I'm using the GitHub head on FreeBSD.

Dale
-----
Transparency with Trust
http://www.dalescot.net

Re: [mdb-dev] PHP and ODBC leaving lots of files open

[Mike P. <mj...@fi...>]

Hi guys,

Chris - thanks again for the ideas, sadly didn't cut it....

.....because I discovered something else...

Having got to the point of tracing the UnixODBC calls, I could see that 
SQLConnect was being called followed by SQLDisconnect.

What I then discovered is that in odbc.c, SQLConnect calls 
mdb_sql_open() as you'd expect..... but the corresponding SQLDisconnect 
didn't do anything - most especially, it didn't call mdb_sql_close()!!

So, anyway, I submit a change to odbc.c for your pleasure:-

SQLRETURN SQL_API SQLDisconnect(
     SQLHDBC            hdbc)
{
    struct _hdbc *dbc = (struct _hdbc *) hdbc;
    struct _henv *env = (struct _henv *) dbc->henv;

    TRACE("SQLDisconnect");

    mdb_sql_close(env->sql);

    return SQL_SUCCESS;
}


Fixing the code and recompiling causes my issue to go away.  Quite why 
this hasn't been noticed before is a bit of a mystery (me included!) but 
I hope this discovery helps someone out there.

-- 

Cheers,

Mike

mj...@fi...                                 http://www.filmsat59.com
Films at 59 Ltd, 59 Cotham Hill, Bristol. BS6 6JR ENGLAND +44 117 906 4300

Re: [mdb-dev] PHP and ODBC leaving lots of files open

[Chris C. <cc...@fi...>]

I have limited experience with PHP, but maybe I can muddle through...

On 22/01/13 05:54 AM, Mike Prudence wrote:
 >      if (odbc_fetch_row($result))
 >         $retval = odbc_result($result, 'Name');
 >      else
 >         $retval = "Unknown";

What if there are more rows?

You should more likely do something like:

	if (odbc_fetch_row($result, 0))
		$retval = odbc_result($result, 'Name');
	else
		$retval = "Unknown";

	while(odbc_fetch_row($result)) {
		// do something with the extra results (or not)
	}

Or maybe you could call odbc_free_result before odbc_commit and odbc_close.

-- 
Chris Craig
Software Developer
Fibernetics Corp
605 Boxwood Dr
Cambridge ON  N3E 1A5
519-489-6700 x 753

Re: [mdb-dev] PHP and ODBC leaving lots of files open

[Mike P. <mj...@fi...>]

Hi Chris,

Thanks for the hint.....but to no avail, sadly.

Here's the code in case anyone can spot my stupidity:-

function getClientName($s)
{
    $myDB = odbc_connect("Clients", "", "");
    $query = "select Name from Clients where ID = '".$s."'";
    $result = odbc_exec($myDB, $query);

    if (odbc_fetch_row($result))
       $retval = odbc_result($result, 'Name');
    else
       $retval = "Unknown";

    odbc_commit($myDB);
    odbc_close($myDB);
    return $retval;
}

Running this leaves my clients.mdb file open by the apache process 
according to lsof -ap.

Puzzling....

-- 

Cheers,

Mike

mj...@fi...                                 http://www.filmsat59.com
Films at 59 Ltd, 59 Cotham Hill, Bristol. BS6 6JR ENGLAND +44 117 906 4300

Re: [mdb-dev] PHP and ODBC leaving lots of files open

[Chris C. <cc...@fi...>]

On 21/01/13 01:26 PM, Mike Prudence wrote:
 > the scripts, I discover that none of my 'odbc_close()' calls appear to
 > have closed the .mdb file that I assume 'odbc_open()' has opened.
 >
 > Surely if I use odbc_close() it should be closing the .mdb file it has
 > opened, no ?  Or have I missed something blindingly obvious ?

I would guess you still have transactions pending, so it's not closing. 
See: http://php.net/manual/en/function.odbc-close.php

"This function will fail if there are open transactions on this 
connection. The connection will remain open in this case."

You could try running odbc_commit before the close...

-- 
Chris Craig
Software Developer
Fibernetics Corp
605 Boxwood Dr
Cambridge ON  N3E 1A5
519-489-6700 x 753

[mdb-dev] PHP and ODBC leaving lots of files open

[Mike P. <mj...@fi...>]

Hi guys,

Bit of a stab in the dark, but I thought I'd ask the list if anyone has 
seen anything like this - Google hasn't helped me thus far.

We've got a bunch of PHP scripts using mbdtools via odbc.  I've just 
noticed that if I use 'lsof -ap' on one of the httpd processes running 
the scripts, I discover that none of my 'odbc_close()' calls appear to 
have closed the .mdb file that I assume 'odbc_open()' has opened.

This has become a problem because with more people using the scripts, 
the open files build up and up until the process breaks because it has 
too many open files.

Surely if I use odbc_close() it should be closing the .mdb file it has 
opened, no ?  Or have I missed something blindingly obvious ?

Thanks, as always, for any hints/help...

-- 

Cheers,

Mike

mj...@fi...                                 http://www.filmsat59.com
Films at 59 Ltd, 59 Cotham Hill, Bristol. BS6 6JR ENGLAND +44 117 906 4300

Re: [mdb-dev] Command line option to suppress binary data

[Alfonso Muñoz-P. F. <alf...@vt...>]

Thanks! I’ve already pulled from the Github repo and the code I added 
was pretty much the same ;)

Great work. I’ll let you know how the octal thing works for testing 
purposes. I pretty much settled on discarding the replication fields, 
though.

Regards.

On 05/12/12 15:09, Nirgal wrote:
> I added a simmilar option in repository last Sunday (!)
>
> Source is available at:
> https://github.com/brianb/mdbtools/archive/master.tar.gz
>
> You can now use -b strip to remove the binary data.
>
> Also, I could export the binary data into a postgres database using octal encoding, with new option -b octal.
> I then used psql COPY command to import the data, but somehow, I had to replace \ by \\ in the csv file first (sed -e s/\\/\\\\/g)
>
> See existing bug repport at:
> https://github.com/brianb/mdbtools/issues/16
> https://bugs.launchpad.net/ubuntu/+source/mdbtools/+bug/390730
>
> Cheers
>
> On Monday 03 December 2012 17:15:35 Alfonso Muñoz-Pomer Fuentes wrote:
>> Hi again.
>>
>> In the database we’re migrating from Access to PostgreSQL we have some
>> fields which contain binary data. They’re used for replication so they
>> can be safely ignored for the migration process. The issue is that there
>> are certain rows in which these binary fields may contain escape
>> sequences which break the import to PostgreSQL. I’ve added a command
>> line option (-B) to skip binary data with blank fields.
>>
>> I don’t know if this is a known issue and if such a workaround would be
>> welcome.
>>
>>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
>

-- 
Alfonso Muñoz-Pomer Fuentes
Johann Heinrich von Thünen-Institut
Bundesforschungsinstitut für Ländliche Räume, Wald und Fischerei
Institut für Forstgenetik
Sieker Landstrasse 2
22927 Grosshansdorf

Telefon: +49 (0)4102/696-145
Fax:     +49 (0)4102/696-200
Email:   alf...@vt...
Web:     http://www.vti.bund.de

Re: [mdb-dev] Command line option to suppress binary data

[Nirgal <con...@ni...>]

I added a simmilar option in repository last Sunday (!)

Source is available at:
https://github.com/brianb/mdbtools/archive/master.tar.gz

You can now use -b strip to remove the binary data.

Also, I could export the binary data into a postgres database using octal encoding, with new option -b octal.
I then used psql COPY command to import the data, but somehow, I had to replace \ by \\ in the csv file first (sed -e s/\\/\\\\/g)

See existing bug repport at:
https://github.com/brianb/mdbtools/issues/16
https://bugs.launchpad.net/ubuntu/+source/mdbtools/+bug/390730

Cheers

On Monday 03 December 2012 17:15:35 Alfonso Muñoz-Pomer Fuentes wrote:
> Hi again.
> 
> In the database we’re migrating from Access to PostgreSQL we have some 
> fields which contain binary data. They’re used for replication so they 
> can be safely ignored for the migration process. The issue is that there 
> are certain rows in which these binary fields may contain escape 
> sequences which break the import to PostgreSQL. I’ve added a command 
> line option (-B) to skip binary data with blank fields.
> 
> I don’t know if this is a known issue and if such a workaround would be 
> welcome.
> 
> 

[mdb-dev] Command line option to suppress binary data

[Alfonso Muñoz-P. F. <alf...@vt...>]

Hi again.

In the database we’re migrating from Access to PostgreSQL we have some 
fields which contain binary data. They’re used for replication so they 
can be safely ignored for the migration process. The issue is that there 
are certain rows in which these binary fields may contain escape 
sequences which break the import to PostgreSQL. I’ve added a command 
line option (-B) to skip binary data with blank fields.

I don’t know if this is a known issue and if such a workaround would be 
welcome.

-- 
Alfonso Muñoz-Pomer Fuentes
Johann Heinrich von Thünen-Institut
Bundesforschungsinstitut für Ländliche Räume, Wald und Fischerei
Institut für Forstgenetik
Sieker Landstrasse 2
22927 Grosshansdorf

Telefon: +49 (0)4102/696-145
Fax:     +49 (0)4102/696-200
Email:   alf...@vt...
Web:     http://www.vti.bund.de

Re: [mdb-dev] compile error by make

[Chris C. <cc...@fi...>]

See if this helps:

http://sourceforge.net/mailarchive/message.php?msg_id=5998080

-- 
Chris Craig
Software Developer
Fibernetics Corp
605 Boxwood Dr
Cambridge ON  N3E 1A5
519-489-6700 x 753

On 25/11/12 09:47 AM, Cesar Romani wrote:
> I'm building mdbtools from the cvs repository on windows 7 with cygwin.
> By make I get:
>
> --------------------
> [...]
> make[2]: Entering directory `/home/caesar/mdbtools/src/util'
> /bin/sh ../../libtool --tag=CC    --mode=link gcc  -g -O2 -DSQL    -o
> mdb-sql.exe mdb-sql.o ../libmdb/libmdb.la ../sql/libmdbsql.la -lreadline
> -lglib-2.0 -lintl -liconv    -lfl
> libtool: link: gcc -g -O2 -DSQL -o .libs/mdb-sql.exe mdb-sql.o
> ../libmdb/.libs/libmdb.a -L/usr/lib/ncursesw -L/usr/lib
> ../sql/.libs/libmdbsql.a -lreadline /usr/lib/libglib-2.0.dll.a
> /usr/lib/libpcre.dll.a /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a -lfl
> ../sql/.libs/libmdbsql.a(mdbsql.o): In function `mdb_sql_init':
> /home/caesar/mdbtools/src/sql/mdbsql.c:63: undefined reference to
> `_mdb_init'
> ../sql/.libs/libmdbsql.a(mdbsql.o): In function `mdb_sql_add_temp_col':
> /home/caesar/mdbtools/src/sql/mdbsql.c:557: undefined reference to
> `_mdb_fill_temp_col'
> /home/caesar/mdbtools/src/sql/mdbsql.c:558: undefined reference to
> `_mdb_temp_table_add_col'
> ../sql/.libs/libmdbsql.a(mdbsql.o): In function `mdb_sql_listtables':
> /home/caesar/mdbtools/src/sql/mdbsql.c:533: undefined reference to
> `_mdb_create_temp_table'
> /home/caesar/mdbtools/src/sql/mdbsql.c:542: undefined reference to
> `_mdb_fill_temp_field'
> ../sql/.libs/libmdbsql.a(mdbsql.o): In function `mdb_sql_describe_table':
> /home/caesar/mdbtools/src/sql/mdbsql.c:596: undefined reference to
> `_mdb_create_temp_table'
> /home/caesar/mdbtools/src/sql/mdbsql.c:606: undefined reference to
> `_mdb_fill_temp_field'
> /home/caesar/mdbtools/src/sql/mdbsql.c:610: undefined reference to
> `_mdb_fill_temp_field'
> /home/caesar/mdbtools/src/sql/mdbsql.c:614: undefined reference to
> `_mdb_fill_temp_field'
> collect2: ld returned 1 exit status
> Makefile:401: recipe for target `mdb-sql.exe' failed
> make[2]: *** [mdb-sql.exe] Error 1
> make[2]: Leaving directory `/home/caesar/mdbtools/src/util'
> Makefile:275: recipe for target `all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/caesar/mdbtools/src'
> Makefile:352: recipe for target `all-recursive' failed
> make: *** [all-recursive] Error 1
> --------------------
>
> Many thanks in advance,
>

[mdb-dev] compile error by make

[Cesar R. <ces...@gm...>]

I'm building mdbtools from the cvs repository on windows 7 with cygwin.
By make I get:

--------------------
[...]
make[2]: Entering directory `/home/caesar/mdbtools/src/util'
/bin/sh ../../libtool --tag=CC    --mode=link gcc  -g -O2 -DSQL    -o 
mdb-sql.exe mdb-sql.o ../libmdb/libmdb.la ../sql/libmdbsql.la -lreadline 
-lglib-2.0 -lintl -liconv    -lfl
libtool: link: gcc -g -O2 -DSQL -o .libs/mdb-sql.exe mdb-sql.o  
../libmdb/.libs/libmdb.a -L/usr/lib/ncursesw -L/usr/lib 
../sql/.libs/libmdbsql.a -lreadline /usr/lib/libglib-2.0.dll.a 
/usr/lib/libpcre.dll.a /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a -lfl
../sql/.libs/libmdbsql.a(mdbsql.o): In function `mdb_sql_init':
/home/caesar/mdbtools/src/sql/mdbsql.c:63: undefined reference to 
`_mdb_init'
../sql/.libs/libmdbsql.a(mdbsql.o): In function `mdb_sql_add_temp_col':
/home/caesar/mdbtools/src/sql/mdbsql.c:557: undefined reference to 
`_mdb_fill_temp_col'
/home/caesar/mdbtools/src/sql/mdbsql.c:558: undefined reference to 
`_mdb_temp_table_add_col'
../sql/.libs/libmdbsql.a(mdbsql.o): In function `mdb_sql_listtables':
/home/caesar/mdbtools/src/sql/mdbsql.c:533: undefined reference to 
`_mdb_create_temp_table'
/home/caesar/mdbtools/src/sql/mdbsql.c:542: undefined reference to 
`_mdb_fill_temp_field'
../sql/.libs/libmdbsql.a(mdbsql.o): In function `mdb_sql_describe_table':
/home/caesar/mdbtools/src/sql/mdbsql.c:596: undefined reference to 
`_mdb_create_temp_table'
/home/caesar/mdbtools/src/sql/mdbsql.c:606: undefined reference to 
`_mdb_fill_temp_field'
/home/caesar/mdbtools/src/sql/mdbsql.c:610: undefined reference to 
`_mdb_fill_temp_field'
/home/caesar/mdbtools/src/sql/mdbsql.c:614: undefined reference to 
`_mdb_fill_temp_field'
collect2: ld returned 1 exit status
Makefile:401: recipe for target `mdb-sql.exe' failed
make[2]: *** [mdb-sql.exe] Error 1
make[2]: Leaving directory `/home/caesar/mdbtools/src/util'
Makefile:275: recipe for target `all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/caesar/mdbtools/src'
Makefile:352: recipe for target `all-recursive' failed
make: *** [all-recursive] Error 1
--------------------

Many thanks in advance,

-- 
Cesar

Re: [mdb-dev] New member

[Nirgal <con...@ni...>]

On Monday 29 October 2012 08:56:45 Alfonso Muñoz-Pomer Fuentes wrote:
> (...)
> I wanted to know what are the best way to post, suggestions and possible 
> patches. Should I use the SF mailing list, GitHub issues, SF forum or SF 
> bug tracker?

SF forum & bugtracker are dead, as far as I know.

This mailing list and github are active.

Patches are always welcome, either on the list, or in a github.
My personnal preference would be github.

I did some automatic mdb -> postgres migration in the past.
I would recommand exportting the schema without the foreign keys
Then use psql COPY to get the csv file
Then add the foreign keys.
Attached is a an exemple script. "Works for me"© ;)

Cheers