Menu
▾
▴
mdbtools-dev
This list is closed, nobody may subscribe to it.
| 2000 |
Jan
|
Feb
(1) |
Mar
(53) |
Apr
(28) |
May
(5) |
Jun
(7) |
Jul
(16) |
Aug
(15) |
Sep
(10) |
Oct
(1) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(9) |
Feb
(7) |
Mar
(1) |
Apr
(7) |
May
(6) |
Jun
|
Jul
(15) |
Aug
(10) |
Sep
(2) |
Oct
(12) |
Nov
(3) |
Dec
(2) |
| 2002 |
Jan
(2) |
Feb
(12) |
Mar
(33) |
Apr
(30) |
May
(5) |
Jun
(18) |
Jul
(18) |
Aug
(47) |
Sep
(8) |
Oct
(7) |
Nov
(8) |
Dec
(13) |
| 2003 |
Jan
(48) |
Feb
(8) |
Mar
(10) |
Apr
(30) |
May
(6) |
Jun
(8) |
Jul
(19) |
Aug
(36) |
Sep
(19) |
Oct
(16) |
Nov
(11) |
Dec
(17) |
| 2004 |
Jan
(11) |
Feb
(22) |
Mar
(52) |
Apr
(45) |
May
(18) |
Jun
(72) |
Jul
(14) |
Aug
(31) |
Sep
(19) |
Oct
(27) |
Nov
(19) |
Dec
(25) |
| 2005 |
Jan
(16) |
Feb
(46) |
Mar
(50) |
Apr
(3) |
May
(21) |
Jun
(3) |
Jul
(24) |
Aug
(33) |
Sep
(25) |
Oct
(23) |
Nov
(30) |
Dec
(20) |
| 2006 |
Jan
(12) |
Feb
(11) |
Mar
(8) |
Apr
(15) |
May
(27) |
Jun
(15) |
Jul
(19) |
Aug
(5) |
Sep
(9) |
Oct
(1) |
Nov
(2) |
Dec
(3) |
| 2007 |
Jan
|
Feb
(3) |
Mar
(18) |
Apr
(5) |
May
(9) |
Jun
|
Jul
(10) |
Aug
(3) |
Sep
(8) |
Oct
(1) |
Nov
(7) |
Dec
(9) |
| 2008 |
Jan
(2) |
Feb
|
Mar
(10) |
Apr
(4) |
May
|
Jun
(5) |
Jul
(9) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(8) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(1) |
Dec
(20) |
| 2010 |
Jan
|
Feb
(2) |
Mar
|
Apr
(7) |
May
|
Jun
(23) |
Jul
(3) |
Aug
(6) |
Sep
(1) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2011 |
Jan
(1) |
Feb
(26) |
Mar
(25) |
Apr
(11) |
May
(5) |
Jun
(5) |
Jul
(2) |
Aug
(39) |
Sep
(12) |
Oct
(6) |
Nov
|
Dec
|
| 2012 |
Jan
(19) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
(8) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
(3) |
| 2013 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
|
May
(7) |
Jun
(5) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2014 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
(5) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Nirgal <con...@ni...> - 2011-08-25 19:20:12
|
Attached is a patch that will limit the amount of output when building, by default. Try it with after: CFLAGS=-Wall ./configure --with-unixodbc=/usr |
|
From: Vasilis V. <Vas...@ce...> - 2011-08-25 15:15:37
|
Hi all, looking in the source code of mdblib I saw that the column->len_ptr holds the length of the object, then modifying a bit the mdb-export.c to dump *(col->len_ptr) characters I correctly the memo fields in some of the rows, but it fails completely in some other rows. When it fails it report smaller size e.g 521 instead of 2336. >From which variable I can get the correct MEMO size? Vasilis ________________________________ From: Vasilis Vlachoudis [Vas...@ce...] Sent: 25 August 2011 16:27 To: mdb...@li... Subject: [mdb-dev] Memo field with binary data Hi all, I have a database that I want to read from linux, in which the Memo field contains variable length binary data actually a list of double precision numbers. The problems are: 1. The memo is reported with max length of 255, however it contains more than 255 characters. MS-Access it claims that the Memo can be up to 64k 2. Since the memo field contains binary data, it contains also '00'x characters which forces the mdb-export to stop on the first null char, rather dumping the whole string. How can I extract the binary data (length and actual data) unprocessed so I can access the numbers Best Regards Vasilis |
|
From: Vasilis V. <Vas...@ce...> - 2011-08-25 14:27:23
|
Hi all, I have a database that I want to read from linux, in which the Memo field contains variable length binary data actually a list of double precision numbers. The problems are: 1. The memo is reported with max length of 255, however it contains more than 255 characters. MS-Access it claims that the Memo can be up to 64k 2. Since the memo field contains binary data, it contains also '00'x characters which forces the mdb-export to stop on the first null char, rather dumping the whole string. How can I extract the binary data (length and actual data) unprocessed so I can access the numbers Best Regards Vasilis |
|
From: Nirgal <con...@ni...> - 2011-08-25 08:02:03
|
Here's a bunch of patches for cleaning up ABI, that exported symbols not stating with mdb_ nosanitize.diff removes the column name sanitizing options. Now that all backends properly quote names, this is no longer necessary. It is my feeling that it causes more problems that it solve. It tried mdbtools on a Chinese database and got all my tables named "__" for example. sanitize_name was not matching the mdb_* list of exported symbols. prop_abi.diff simply renames kkd_to_props into mdb_kkd_to_props bufferdump.diff simply renames buffer_dump into mdb_buffer_dump These patches apply to git master after one-off-index.diff already posted to the list. |
|
From: Nirgal <con...@ni...> - 2011-08-15 08:03:17
|
Attached if a patch for an index overflow. Found on github, and not published on that list before as far as I can tell. |
|
From: Nirgal <con...@ni...> - 2011-08-11 05:28:16
|
On Wednesday 10 August 2011 22:07:20 Brian Bruns wrote: > All patches are in! Let me know if I missed any. Good new :) But you forgot to add a few files to git, so that they are missing for compilation now. These are from abi.diff: src/libmdb/libmdb.map src/sql/libmdbsql.map src/odbc/libmdbodbc.map |
|
From: Brian B. <br...@br...> - 2011-08-10 22:35:13
|
All patches are in! Let me know if I missed any. Brian On Tue, Aug 9, 2011 at 10:34 AM, Nirgal <con...@ni...> wrote: > On Monday 08 August 2011 21:56:26 Brian Bruns wrote: >> Excellent, my mac is back up and running. I'll likely get to all >> these patches sometime tonight. > > Good :) > > If you are lost, I have a serie of patches there: > http://www.nirgal.com/mdbtools/debian.squeeze/debian/patches/ > > But there are other incompatible ones on github :/ > > > What will be the name of next release? > Does 1.0 comes after 0.6pre1? Or is that 0.6.1? > > > I think we should stop exporting these symbols from libmdb before releasing: > sanitize_name, kkd_to_props, _mdb_put_int16, _mdb_put_int32 and buffer_dump > All other symbols matches the "mdb_*" mask (new map file) > |
|
From: Brian B. <br...@br...> - 2011-08-10 12:24:42
|
Gtk is also used for the gmdb2 tool, so it's an easy fit. I would be amenable to including a "replacements" library for systems where autoconf doesn't find glib. So we would create an API compatible subset for the glib routines we use, and then include it if HAVE_GLIB is not defined. Brian On Wed, Aug 10, 2011 at 4:53 AM, Jakob Egger <jab...@gm...> wrote: > Maybe its a bad timing so shortly before the release, but I was wondering if there is a good reason why the MDB-Tools use GLIB. > > I've looked through the source code, and MDB Tools, and here are the main GLIB features used: > - GLIB typedefs such as guint23, gbool, etc. > - pointer arrays > - hash tables > - gmalloc() and gfree() > > I thought about these things and concluded: > - The GLIB types would be trivial to change to some standard types (such as those from types.h) with a simple search and replace. > - Pointer arrays could be reimplemented from scratch with about 100 lines of code > - hash tables are used only for the backend stuff, but we could rewrite that to just use pointer arrays, there's no need for the speed of hash tables here > - gmalloc() and gfree() could probably be replaced with malloc() and free() > > Why am I thinking about this? Glib is a very heavy library. It depends on gettext and iconv. I haven't yet managed to compile Glib myself on Mac OS, I only managed to do it with MacPorts. But even if you manage to compile Glib, it weighs more than 2MB, plus 2MB for iconv (i didn't manage to link GLIB to the system provided libiconv). That is very large compared to 200KB for libmdb. For small apps thats a lot of wasted disk space. Now, on Linux this is no problem, because Linux users will have GLIB installed. But on Mac OS, the dependency on GLIB makes using mdbtools very difficult and much less portable. > > I think that removing the dependency of GLIB (for the core library) would strongly increase adoption of libmdb. > > What are your thoughs on the matter? > > Best regards, > Jakob Egger > > > On 09.08.2011, at 16:34, Nirgal wrote: > >> On Monday 08 August 2011 21:56:26 Brian Bruns wrote: >>> Excellent, my mac is back up and running. I'll likely get to all >>> these patches sometime tonight. >> >> Good :) >> >> If you are lost, I have a serie of patches there: >> http://www.nirgal.com/mdbtools/debian.squeeze/debian/patches/ >> >> But there are other incompatible ones on github :/ >> >> >> What will be the name of next release? >> Does 1.0 comes after 0.6pre1? Or is that 0.6.1? >> >> >> I think we should stop exporting these symbols from libmdb before releasing: >> sanitize_name, kkd_to_props, _mdb_put_int16, _mdb_put_int32 and buffer_dump >> All other symbols matches the "mdb_*" mask (new map file) >> >> ------------------------------------------------------------------------------ >> uberSVN's rich system and user administration capabilities and model >> configuration take the hassle out of deploying and managing Subversion and >> the tools developers use with it. Learn more about uberSVN and get a free >> download at: http://p.sf.net/sfu/wandisco-dev2dev >> _______________________________________________ >> mdbtools-dev mailing list >> mdb...@li... >> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev > > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > mdbtools-dev mailing list > mdb...@li... > https://lists.sourceforge.net/lists/listinfo/mdbtools-dev > |
|
From: Alexander L. <le...@ed...> - 2011-08-10 09:42:50
|
On Wed, 10 Aug 2011, Jakob Egger wrote: > Maybe its a bad timing so shortly before the release, but I was wondering if there is a good reason why the MDB-Tools use GLIB. > > I've looked through the source code, and MDB Tools, and here are the main GLIB features used: > - GLIB typedefs such as guint23, gbool, etc. > - pointer arrays > - hash tables > - gmalloc() and gfree() > > I thought about these things and concluded: > - The GLIB types would be trivial to change to some standard types (such as those from types.h) with a simple search and replace. > - Pointer arrays could be reimplemented from scratch with about 100 lines of code > - hash tables are used only for the backend stuff, but we could rewrite that to just use pointer arrays, there's no need for the speed of hash tables here > - gmalloc() and gfree() could probably be replaced with malloc() and free() > > Why am I thinking about this? Glib is a very heavy library. It depends on gettext and iconv. I haven't yet managed to compile Glib myself on Mac OS, I only managed to do it with MacPorts. But even if you manage to compile Glib, it weighs more than 2MB, plus 2MB for iconv (i didn't manage to link GLIB to the system provided libiconv). That is very large compared to 200KB for libmdb. For small apps thats a lot of wasted disk space. Now, on Linux this is no problem, because Linux users will have GLIB installed. But on Mac OS, the dependency on GLIB makes using mdbtools very difficult and much less portable. > > I think that removing the dependency of GLIB (for the core library) would strongly increase adoption of libmdb. > > What are your thoughs on the matter? > I solved this problem by providing the required glib types and functions myself. The hash is implemented using STL containers. Of course it is not any longer a plain-C project, but for my needs it did the job. If you are interested, I can offer my code. Its one header and one source without touching the mdblib sources. Alex. |
|
From: Jakob E. <jab...@gm...> - 2011-08-10 09:01:21
|
Maybe its a bad timing so shortly before the release, but I was wondering if there is a good reason why the MDB-Tools use GLIB. I've looked through the source code, and MDB Tools, and here are the main GLIB features used: - GLIB typedefs such as guint23, gbool, etc. - pointer arrays - hash tables - gmalloc() and gfree() I thought about these things and concluded: - The GLIB types would be trivial to change to some standard types (such as those from types.h) with a simple search and replace. - Pointer arrays could be reimplemented from scratch with about 100 lines of code - hash tables are used only for the backend stuff, but we could rewrite that to just use pointer arrays, there's no need for the speed of hash tables here - gmalloc() and gfree() could probably be replaced with malloc() and free() Why am I thinking about this? Glib is a very heavy library. It depends on gettext and iconv. I haven't yet managed to compile Glib myself on Mac OS, I only managed to do it with MacPorts. But even if you manage to compile Glib, it weighs more than 2MB, plus 2MB for iconv (i didn't manage to link GLIB to the system provided libiconv). That is very large compared to 200KB for libmdb. For small apps thats a lot of wasted disk space. Now, on Linux this is no problem, because Linux users will have GLIB installed. But on Mac OS, the dependency on GLIB makes using mdbtools very difficult and much less portable. I think that removing the dependency of GLIB (for the core library) would strongly increase adoption of libmdb. What are your thoughs on the matter? Best regards, Jakob Egger On 09.08.2011, at 16:34, Nirgal wrote: > On Monday 08 August 2011 21:56:26 Brian Bruns wrote: >> Excellent, my mac is back up and running. I'll likely get to all >> these patches sometime tonight. > > Good :) > > If you are lost, I have a serie of patches there: > http://www.nirgal.com/mdbtools/debian.squeeze/debian/patches/ > > But there are other incompatible ones on github :/ > > > What will be the name of next release? > Does 1.0 comes after 0.6pre1? Or is that 0.6.1? > > > I think we should stop exporting these symbols from libmdb before releasing: > sanitize_name, kkd_to_props, _mdb_put_int16, _mdb_put_int32 and buffer_dump > All other symbols matches the "mdb_*" mask (new map file) > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > mdbtools-dev mailing list > mdb...@li... > https://lists.sourceforge.net/lists/listinfo/mdbtools-dev |
|
From: Nirgal <con...@ni...> - 2011-08-09 14:35:41
|
On Monday 08 August 2011 21:56:26 Brian Bruns wrote: > Excellent, my mac is back up and running. I'll likely get to all > these patches sometime tonight. Good :) If you are lost, I have a serie of patches there: http://www.nirgal.com/mdbtools/debian.squeeze/debian/patches/ But there are other incompatible ones on github :/ What will be the name of next release? Does 1.0 comes after 0.6pre1? Or is that 0.6.1? I think we should stop exporting these symbols from libmdb before releasing: sanitize_name, kkd_to_props, _mdb_put_int16, _mdb_put_int32 and buffer_dump All other symbols matches the "mdb_*" mask (new map file) |
|
From: Brian B. <br...@br...> - 2011-08-08 21:56:33
|
Excellent, my mac is back up and running. I'll likely get to all these patches sometime tonight. Brian On Mon, Aug 8, 2011 at 4:04 PM, Nirgal <con...@ni...> wrote: > That patch unexport 3 symbols for libmdbsql: > > mdb-sql and gmdb2 now properly call mdb_sql_run_query rather than accessing the yacc variables directly. > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > The must-attend event for mobile developers. Connect with experts. > Get tools for creating Super Apps. See the latest technologies. > Sessions, hands-on labs, demos & much more. Register early & save! > http://p.sf.net/sfu/rim-blackberry-1 > _______________________________________________ > mdbtools-dev mailing list > mdb...@li... > https://lists.sourceforge.net/lists/listinfo/mdbtools-dev > > |
|
From: Nirgal <con...@ni...> - 2011-08-08 20:04:43
|
That patch unexport 3 symbols for libmdbsql: mdb-sql and gmdb2 now properly call mdb_sql_run_query rather than accessing the yacc variables directly. |
|
From: Nirgal <con...@ni...> - 2011-08-07 20:25:19
|
Hi everyone
I started checking how to release, and I have a 2 main questions:
1. The code is still using a few svn $Id $Revision $Date magic tags here and there.
Attached is a patch version.patch to remove them.
This patch boldly removes unused versioning vars in libraries such as:
include/mdbodbc.h : rcsid_sql_h = "$Id: mdbodbc.h,v 1.5 2005/01/15 05:02:13 calvinrsmith Exp $"
src/odbc/odbc.c: software_version = "$Id: odbc.c,v 1.31 2007/03/18 14:11:43 brianb Exp $"
src/odbc/unittest.c: software_version = "$Id: unittest.c,v 1.8 2005/04/29 03:08:22 whydoubt Exp $"
I could not see these symbols exported in the public API, so I guess this is ok.
What do you think?
We could also keep them, and use include/mdbver.h to generate these strings.
Weird version numbers are left in doc/install.sgml
2. Regarding ABI:
Version 0.6pre1 ships with these version of librairies:
libmdbodbc.so.0.0.0
libmdb.so.1.0.0
libmdbsql.so.1.0.0
All libraries have lost symbols, so we'll have to use:
libmdbodbc.so.1.0.0
libmdb.so.2.0.0
libmdbsql.so.2.0.0
Actually, we are still exporting some "internal" symbols, like:
yy_create_buffer
_mdb_put_int16
MdbJet3Constants
...
I guess it would make sense to hide these internal references, so that we minimise future bumps in so names.
I started to write a map file. My first though is that we should export mdb_*
But there are a 5 additonal symbols used here and there:
sanitize_name
kkd_to_props
_mdb_put_int16
_mdb_put_int32
buffer_dump
I suggest we rename this functions in mdb_something, or find a way to stop using them outside of libmdb.
Starting with sanitize_name, that is no longer needed IMHO, since all backends now quote properly the names. I would vote for droping its support. Code is complex in mdb-export and backend because of it: in backend.c this is almost like we have a special backend. But people might use it... (mdb-export, mdb-schema)
Alternative is to rename it into mdb_sanitize_name.
Your thoughts?
In libmdbsql, we have to export these symbols needed by gmdb2:
mdb_sql_*
g_input_ptr
_mdb_sql
yyparse
I guess everybody agrees this should be changed... Help welcomed.
Regarding libodbc, it is linked static with libmdb and libmdbsql ??
So the number of exported symbol was huge.
The map file I created only export SQL*
This has to be tested.
Is there a good reason to duplicate the code in that library?
Test version for debian here:
http://www.nirgal.com/mdbtools/debian.squeeze/
|
|
From: <mar...@or...> - 2011-08-06 00:54:42
|
This is an auto-replied message. I am out of office until Monday, August 8th. I will have limited access to phone and email. Just send an email and I'll respond as soon as I can. If it is urgent, please contact Geoff Trembley Geo...@or... 314-422-8446 I will return your email as soon as I can. Happy Computing!!! <<Martin>> |
|
From: Nirgal <con...@ni...> - 2011-08-06 00:53:51
|
Here's patch taken from Debian tracking system, by xsloader <xsl...@xs...>, slightly modified to apply to git master. http://bugs.debian.org/514986 This fixes SQLGetData() that must returns SQL_NO_DATA at end of data This also adds support for DBQ in connection strings, and unicode API. I have not tested it beyond the fact that it compiles. It looks ok, however. |
|
From: Nirgal <con...@ni...> - 2011-08-05 14:36:42
|
Here's a patch for oracle numeric type export bugs described at http://bugs.debian.org/358670 |
|
From: Tim R. <di...@de...> - 2011-08-05 08:49:29
|
On 5 August 2011 00:04, Nirgal <con...@ni...> wrote: > Distros will avoid releasing a snapshot that breaks exported symbols from libraries. So people are stuck with old problems. This is quite important - we do need a soname bump in the next release! And it would be best to do this upstream, so that it's standard across distros. We can get you a list of what's changed if you need it.. -- Tim Retout <di...@de...> |
|
From: Brian B. <br...@br...> - 2011-08-04 23:10:46
|
Hi Nirgal, Yes, we are way overdue for a release. I'm having some problems with my machine which should be resolved today and then I'll start merging and testing whatever is still outstanding. I saw your patch from earlier, I'll get that in shortly, but if anyone else has patches which have not been merged, ping me because I probably lost them. Brian On Thu, Aug 4, 2011 at 7:04 PM, Nirgal <con...@ni...> wrote: > On Friday 22 July 2011 19:29:16 Seb wrote: >> (...) >> Is this a bug? > > On Tuesday 02 August 2011 20:26:53 Nirgal wrote: >> You might want to try a recent snapshot. There has been a number of change since 2005. >> (...) > > > Hi Brian > > Don't you think it is time to release a new version? > > There has been a lot of changes in the last year. I'm sure people miss them! > > I can try to help if you want. > > Distros will avoid releasing a snapshot that breaks exported symbols from libraries. So people are stuck with old problems. > |
|
From: Nirgal <con...@ni...> - 2011-08-04 23:04:42
|
On Friday 22 July 2011 19:29:16 Seb wrote: > (...) > Is this a bug? On Tuesday 02 August 2011 20:26:53 Nirgal wrote: > You might want to try a recent snapshot. There has been a number of change since 2005. > (...) Hi Brian Don't you think it is time to release a new version? There has been a lot of changes in the last year. I'm sure people miss them! I can try to help if you want. Distros will avoid releasing a snapshot that breaks exported symbols from libraries. So people are stuck with old problems. |
|
From: Nirgal <con...@ni...> - 2011-08-04 22:51:48
|
Here's a bunch of fixes for compilation warnings, mostly unused vars. |
|
From: Tim R. <di...@de...> - 2011-08-03 14:04:17
|
On 2 August 2011 21:26, Nirgal <con...@ni...> wrote: > You might want to try a recent snapshot. There has been a number of change since 2005. > One is available there: > http://www.nirgal.com/mdbtools/debian.squeeze/ Hey, I recently offered mdbtools for adoption, because I don't have time to keep it up to date in Debian. Would you like to become the maintainer? I can help sponsor the packages. Kind regards, -- Tim Retout <di...@de...> |
|
From: Nirgal <con...@ni...> - 2011-08-02 21:03:52
|
You might want to try a recent snapshot. There has been a number of change since 2005. One is available there: http://www.nirgal.com/mdbtools/debian.squeeze/ On Friday 22 July 2011 19:29:16 Seb wrote: > Hi, > > I'm using version 0.5.99.0.6pre1.0.20051109-7.1 (Debian sid), and > noticed that a field with type Number, field size Decimal, Precision 3, > and scale 0, shows fine in MS Access. Some rows: > > -2 > -1 > 2 > 3 > > mdb-export exports as: > > 002 > 001 > 002 > 003 > > If I change the field properties in MS Access to Number, field size > Double, then mdb-export exports properly. However, the column order in > the output gets altered, with the modified column being output last. > This causes some problems for scripting. > > Is this a bug? > > Cheers, > > |
|
From: Jakob E. <jab...@gm...> - 2011-07-26 17:21:10
|
The problem with decimals has been discussed on the mailing list before: http://sourceforge.net/mailarchive/forum.php?thread_name=4DA2EF69.7000602%40fibernetics.ca&forum_name=mdbtools-dev I have posted a patch, but I don't know if my bugfix has been integrated into the main repository yet. you can download the mdb tools source from my fork on github at https://github.com/jakob/mdbtools/tree/mdbviewer Re Column Ordering: I think the mdb tools export columns in the order that they are stored internally. When you alter a column, the original column is marked as deleted and a new column is appended. Try repairing/compacting the database (in Access) to restore the proper column order when using mdb-export. Best regards, Jakob On 22.07.2011, at 21:29, Seb wrote: > Hi, > > I'm using version 0.5.99.0.6pre1.0.20051109-7.1 (Debian sid), and > noticed that a field with type Number, field size Decimal, Precision 3, > and scale 0, shows fine in MS Access. Some rows: > > -2 > -1 > 2 > 3 > > mdb-export exports as: > > 002 > 001 > 002 > 003 > > If I change the field properties in MS Access to Number, field size > Double, then mdb-export exports properly. However, the column order in > the output gets altered, with the modified column being output last. > This causes some problems for scripting. > > Is this a bug? > > Cheers, > > -- > Seb > > > ------------------------------------------------------------------------------ > 10 Tips for Better Web Security > Learn 10 ways to better secure your business today. Topics covered include: > Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, > security Microsoft Exchange, secure Instant Messaging, and much more. > http://www.accelacomm.com/jaw/sfnl/114/51426210/ > _______________________________________________ > mdbtools-dev mailing list > mdb...@li... > https://lists.sourceforge.net/lists/listinfo/mdbtools-dev |
|
From: Seb <sp...@gm...> - 2011-07-22 19:29:48
|
Hi, I'm using version 0.5.99.0.6pre1.0.20051109-7.1 (Debian sid), and noticed that a field with type Number, field size Decimal, Precision 3, and scale 0, shows fine in MS Access. Some rows: -2 -1 2 3 mdb-export exports as: 002 001 002 003 If I change the field properties in MS Access to Number, field size Double, then mdb-export exports properly. However, the column order in the output gets altered, with the modified column being output last. This causes some problems for scripting. Is this a bug? Cheers, -- Seb |
26 messages has been excluded from this view by a project administrator.
