mdbtools-dev

Re: [mdb-dev] Patches + thoughts

[Brian B. <br...@br...>]

Both applied.

Off the top of my head I don't know a reason we would not escape the
escape character.

The insert code was a patch written by someone else, and I think it
was written in the least obtrusive way (leaving the mainline code
alone and putting it all in export.c), so lacks a certain
cohesiveness.  I'm not faulting the author at all, I should have
reworked the code and integrated it better.

If I read you correctly, you are thinking of having mdb-schema (and
the gui version thereof) generate something like mysqldump or pg_dump
with all schemas, tables, data, keys, etc... in sequence?  I think
it's a good idea.  Next time I'm messing in that area, I'll see what
is to be done.

Brian

2011/2/19 Nirgal Vourgère <con...@ni...>:
> On Friday 18 February 2011 19:38:19 Brian Bruns wrote:
>> I'd like to keep quote/escape (particularly quote, I can't think of a
>> case where escape is more than one char) as a string since it allows a
>> multicharacter delimiter, not as uncommon a convention as you might
>> think.
>
> Right.
> Attached is a revised version of export patch.
>
> That does not really anwser my question: "Should we escape the escape character ?"
> My patch does.
> If you or anyone don't like it, there is a #define DONT_ESCAPE_ESCAPE
>
> Attached is an update for Binary type (should not be treated as Memo).
>
>> I agree that the escaping needs some work as it is often not as simple
>> as adding a simple leading character, but that gets a little
>> complicated and we'd have to bake in some escaping styles rather than
>> the generic switch we now have.
>
> I agree.
>
> But I bet the INSERT version of mdb-export doesn't support charcters < 32 right now, nor non-utf8 characters above 127 (OLE).
>
> I guess the best solution would be to move the INSERT code into the schema exportation tools (backend.c).
> The insert would then occur before foreign keys setup. We could also set up the sequences (autonum/serial) automatically then. And have a full mdb->sql conversion tool with both schema and data.
>
> I don't really have the time for that. Would that be a good idea?
>
>> On unicode2ascii, I have no clue how string compression would work for
>> BIG5, but otherwise it basically punts on the overrun question, it's
>> up to the calling function to properly allocate the size which is
>> generally MDB_BIND_SIZE, which is 4 times the page size, so that
>> should accommodate any code set.
>
> I hit some surprised with props, because I was careless of the unciode conversion expanding size problem at first. I mean column name sizes.
> Anyways. I was thinking about Memo fields. I though the limit was 16k, so that mdbtools might fail after utf-8 conversion.
> But Memo field limit actually is 64k chars (192k bytes in utf-8), so we are in trouble anyways.
>
> Maybe all LVal should be handled the same way, with no automatic binding. We now have 3 versions of lval reading in data.c...
>
> Here's another hint: The table/column props internally have:
> - Name
> - type (like col_type)
> - Buffer (pointer + size)
> Right now, we are converting everything to a proper string, meaning we loose the type. We might want a kind of MdbVariant (type+buffer) that could be played with. Like numeric/date operations.
>
> I have the feeling a MdbVariant might be usefull for binding too. We could probably wrap a LVal reader in it.
>
> Ok, I stop daydreaming now... :)
>

Re: [mdb-dev] Patches + thoughts

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

On Friday 18 February 2011 19:38:19 Brian Bruns wrote:
> I'd like to keep quote/escape (particularly quote, I can't think of a
> case where escape is more than one char) as a string since it allows a
> multicharacter delimiter, not as uncommon a convention as you might
> think.

Right.
Attached is a revised version of export patch.

That does not really anwser my question: "Should we escape the escape character ?"
My patch does.
If you or anyone don't like it, there is a #define DONT_ESCAPE_ESCAPE

Attached is an update for Binary type (should not be treated as Memo).

> I agree that the escaping needs some work as it is often not as simple
> as adding a simple leading character, but that gets a little
> complicated and we'd have to bake in some escaping styles rather than
> the generic switch we now have.

I agree.

But I bet the INSERT version of mdb-export doesn't support charcters < 32 right now, nor non-utf8 characters above 127 (OLE).

I guess the best solution would be to move the INSERT code into the schema exportation tools (backend.c).
The insert would then occur before foreign keys setup. We could also set up the sequences (autonum/serial) automatically then. And have a full mdb->sql conversion tool with both schema and data.

I don't really have the time for that. Would that be a good idea?

> On unicode2ascii, I have no clue how string compression would work for
> BIG5, but otherwise it basically punts on the overrun question, it's
> up to the calling function to properly allocate the size which is
> generally MDB_BIND_SIZE, which is 4 times the page size, so that
> should accommodate any code set.

I hit some surprised with props, because I was careless of the unciode conversion expanding size problem at first. I mean column name sizes.
Anyways. I was thinking about Memo fields. I though the limit was 16k, so that mdbtools might fail after utf-8 conversion.
But Memo field limit actually is 64k chars (192k bytes in utf-8), so we are in trouble anyways.

Maybe all LVal should be handled the same way, with no automatic binding. We now have 3 versions of lval reading in data.c...

Here's another hint: The table/column props internally have:
- Name
- type (like col_type)
- Buffer (pointer + size)
Right now, we are converting everything to a proper string, meaning we loose the type. We might want a kind of MdbVariant (type+buffer) that could be played with. Like numeric/date operations.

I have the feeling a MdbVariant might be usefull for binding too. We could probably wrap a LVal reader in it.

Ok, I stop daydreaming now... :)

Re: [mdb-dev] Patches

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

On Thursday 17 February 2011 00:23:45 Brian Bruns wrote:
> All patches applied to master.

Great :)
I've been posting these patches on the list, but the post broke the 40KB message limit.

> Am I correct in surmising that the
> git.diff patch brings the code from 0.6pre1 to the current (prior to
> the other patches) git repository level?

You were absolutly right to ignore that one.
This is because I'm using Debian packaging and it always use the last original tar as a reference.

> I have noticed a couple of problems after applying the patches.
> First, the 'ole' patch changes mdb-export.c/print_col()
> -        if (strlen(quote_char)==1 && c==quote_char[0]) {
> +        if (strlen(quote_char)==1 && c==quote_char[0] || c==escape_char[0]) {
> But if -X is not passed to mdb-export, then escape_char is NULL and we
> segfault on the above code.  Possibly a misapplied patch, but can you
> check it on your local copy?

Yes, this is a bug I introduced, trying to escape both the the escape char and the quote char, rather than only the quote char. I think we should escape the escape char. What is your opinion?
Attached is a fix patch.
I took the liberty to reorganize things a bit:
quote_char and escape_char are now just of type char rather than strings. It simplifies thing a lot.
I also added warning in option parsing, when quote char and escape char lengths are <>1. They were ignoring then.

I submited to the list only a tiny fraction of the patches I've been writing for that small print_col function.
I've been confused by the fact that print_col is used both for INSERT and CSV.
I'm afraid this is just not possible.
Right now, I think CSV is working ok. But INSERT is broken for ole/binary values, and probably for control characters (<32) too.
I think we need some dialect specific code for INSERT, since each backend migth escape the strings & blob in their own way. IMHO, we need a function similar to MdbBackend->quote_schema_name. Eg postgresql E'...' and X'...' formats.

Attached is "export" diff file anyways.

> Secondly, I am getting a message of 'Warning: incorrect memo length'
> on a database that previously did not emit that error.  I need to
> check into this one a bit more.

That problem was because I was trying to handle MDB_BINARY type like MDB_MEMO. This was wrong, especially because there is no unicode encoding. We need to handle them more like OLE I guess.

Note that I can see a problem with memo length computation, just like the OLE length computation was broken, with the 4 extra bytes of the chunk length being taken into account.

Attached is "binaries" diff file.


Another note: I've been working with a JET3 chinese database using BIG5 charset, and I had quite a lot of bad surprises with buffer sizes, with unicode2ascii that can triple the size of data. We potentially have overflows there.

-- 
- - Nirgal Vourgère ☮ GPI IT ☮ tel:+33.1.44.64.02.96
-   xmpp:ni...@ni... ☮ gpg 0x4760b41db292ab13 ☮ skype:nirgal_v
    nirgal.com:qotd ☮ Be the change you want to see in the world -- Gandhi

Re: [mdb-dev] [patch] exporting indexes (v2)

[Brian B. <br...@br...>]

Hi Nirgal,

All patches applied to master.  Am I correct in surmising that the
git.diff patch brings the code from 0.6pre1 to the current (prior to
the other patches) git repository level?

I have noticed a couple of problems after applying the patches.

First, the 'ole' patch changes mdb-export.c/print_col()

-        if (strlen(quote_char)==1 && c==quote_char[0]) {
+        if (strlen(quote_char)==1 && c==quote_char[0] || c==escape_char[0]) {

But if -X is not passed to mdb-export, then escape_char is NULL and we
segfault on the above code.  Possibly a misapplied patch, but can you
check it on your local copy?

Secondly, I am getting a message of 'Warning: incorrect memo length'
on a database that previously did not emit that error.  I need to
check into this one a bit more.

Brian

2011/2/10 Nirgal Vourgère <con...@ni...>:
> I can see the patch about exporting indexes is not in the repository yet.
> It's good, so I had time to refine it a bit, renaming the function to match other ones, and changing the boolean parameters into a bits field (many more options coming soon).
>
> Here's a summary:
> * I was fed up with adding code both in util/mdb-schema.c and gmdb2/schema.c. These were mostly duplicated code.
> So I moved the common parts in libmdb/backend.c, that means a new function called "mdb_print_schema" that will call the relevant code.
>
> * Indexed now are generated for postgres backend: normal ones, unique ones, and primary keys.
>
> * Fixed a bug in where all the foreign keys were generated when you export only one table (added a parameter to mdb_get_relationships).
>
> * Now using PATH_MAX and MDB_MAX_OBJ_NAME macro for sizes of constants in gmdb2/schema.c, rather than hardcoded values 256/100.
>
> * The recent mdb_get_sequences was made static. It might change in the future (export autonum directly for some backend).
>
>
> I updated the other patches I'm working on in http://www.nirgal.com/mdbtools/debian.squeeze/debian/patches/
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
>
>

[mdb-dev] [patch] exporting indexes (v2)

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

I can see the patch about exporting indexes is not in the repository yet.
It's good, so I had time to refine it a bit, renaming the function to match other ones, and changing the boolean parameters into a bits field (many more options coming soon).

Here's a summary:
* I was fed up with adding code both in util/mdb-schema.c and gmdb2/schema.c. These were mostly duplicated code.
So I moved the common parts in libmdb/backend.c, that means a new function called "mdb_print_schema" that will call the relevant code.

* Indexed now are generated for postgres backend: normal ones, unique ones, and primary keys.

* Fixed a bug in where all the foreign keys were generated when you export only one table (added a parameter to mdb_get_relationships).

* Now using PATH_MAX and MDB_MAX_OBJ_NAME macro for sizes of constants in gmdb2/schema.c, rather than hardcoded values 256/100.

* The recent mdb_get_sequences was made static. It might change in the future (export autonum directly for some backend).


I updated the other patches I'm working on in http://www.nirgal.com/mdbtools/debian.squeeze/debian/patches/

[mdb-dev] More patches soon ...

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

Hello MDB folks

Attached are a bunch of new patches for the github repository. These are work in progress, and they assume you first merged "schema-indexes".

"ole" provide a new function called mdb_ole_read_full to easily read a full ole field, with all the chunks.
I already described it yesterday.
IMHO, the whole LVAL system should be rewrote to provide and use a unique interface. This would change the API.
How bad would that be?
Do you know any real usage for libmdb other than gmdb2 and command line tools provided?

"props" finaly works:
catalog.c read the props, table.c assign them.
prtable have been change to display them.
I want to make sure I have some feed back about ole patch before proposing it for merge...
And that code still need some cleaning.
\o/

You'll not want to merge "schema2" yet for sure, as it assumes you use postgres backend.
I include it nevertheless so you can see what we're about to get:
- NOT NULL constrainst
- Not empty constraints
- Columns comments
And soon, hopefully:
- Short date/Long date behaviour
- Default values

Attached is also an example of output...

Cheers!

Re: [mdb-dev] Write Support - Port or write?

[Brian B. <br...@br...>]

I looked at Jackcess some time ago with the intention of figuring out
what they knew about updates that we didn't.

A comment on the current state of MDB Tools and writing (at least as
of the last time I worked on it).  It is possible (or at least was,
I'm suspecting I mismanaged some code and lost my last changes.
Nevertheless they where not extensive) to use mdb-import to write rows
into a table and them read them back successfully using MDB Tools.
What doesn't work is reading them back with Access.  This indicates
that the problem lies in our updating of allocation maps, indexes, or
some other meta-data which understanding the Jackcess code would
hopefully illuminate.  I don't think directly porting would be very
worthwhile.  Also, once we do get it working we need to added
INSERT/UPDATE to the SQL engine (and by extension the ODBC driver),
etc.

My 2 cents...

2011/2/7 Houston, Dion A Sr CPT MIL USA OSD <dio...@us...>:
> Hi all,
> Once again, I'm looking at this project to add to the GDAL project to
> import/export files in a MDB compatible format.  In desiring to make it as
> open as possible, I don't intend to use Jet.
> As we all know, write support is currently only partially supported in the
> source.  I am aware of another MDB library which does support writing called
> Jackcess, http://jackcess.sourceforge.net/ .  I am neither proficient in
> Java, nor highly knowledgeable on the Jet database format (although I did
> use to work in the group).  It seems like there are two main options:
> - Figure out the write code, possibly using Jackcess and incorporate it into
> MDB Tools
> - Port Jackcess to C++
> Based on collective experience of the group, does anyone have any analysis
> or recommendations of what would be easier?  I looked over the Java source
> and it doesn't seem too complicated, but I don't know what I don't know
> about porting Java.  On the other hand, I don't really know where to begin
> on adding write support to MDB Tools, but I am highly comfortable with
> C/C++.
> Thanks in advance for any wisdom you can impart…
> Dion
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
>
>

[mdb-dev] [rfc] Ole

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

I spend quite some time today, trying to make ole fields work.

We use them in 2 places:
- mdb-export (but we only printed the first chunk of data).
- mdb-prop (but it did not work when the props are in more than a chunk)

In both cases, we need a loop like
- Read the first chunk
- While there are other chunks, get them.

Attached is a patch I'm working on:
A new function
void *mdb_ole_read_full(MdbHandle *mdb, MdbColumn *col, size_t *size)
reads all the chunks and return a plain buffer.

Other major changes:
- mdb_old_read_next now stops when col->cur_blob_pg_row becomes 0, as it should.
- mdb_ole_read_first returns the real size read. It means -4 for type 2 chunks. It's more consistent with the other returned value. Having the extra 4 bytes was why mdb-prop was crashing.
- Changed mdb-prop and mdb-export to use that new function.


I played with catalog.c to automatically loads the LvProp, in yet another path, but it's crashing from time to time. So the included patch is for your information only, I'll fix it soon I hope.

Comments are welcome of course!

Re: [mdb-dev] mdbtools dll on Windows

[Leonardo F. <leo...@gm...>]

If anyone is interested,
I succeeded in running mdbtools, honestly only the command line part of it,
under Windows!
Does anybody know the reason why, connecting to a database with mdb-sql, I
receive the exception "STATUS_ACCESS_VIOLATION"?

2011/2/8 Leonardo Francesconi <leo...@gm...>

> Thanks Alexander, ok,
> I'm starting trying to dump the database with mdbtools now;
> if anyone has some suggest for me, it is welcome!
>
> Thanks!!
>
> 2011/2/8 Alexander Lehner <le...@ed...>
>
>
>>
>> Hi Leonardo,
>>
>> I don't know about such a DLL, but I know that accessing a native
>> C-library (dll) from C# is quite a pain.
>> Depending on what you are planning to do, I would rather suggest to write
>> the database-related code in C, using mdbtools and dump the result in a
>> simple plaintext file which then can be read from C#.
>>
>> A.
>>
>>
>>
>> On Tue, 8 Feb 2011, Leonardo Francesconi wrote:
>>
>>  Dear developers,
>>> I'm an Italian Computer Science student (so excuse me for my English) and
>>> I'm working to access and query some .mdb database with Visual Studio C#.
>>> Unfortunately to handle these database I need to be part of the workgroup
>>> described into a .mdw file, and I don't have any password to do that.
>>> Of course mdbtools can access them, so I'm wondering if there exists a
>>> collection of .dll with the mdbtools algorithms to be added to my C#
>>> project, and in that case, how could I use them.
>>>
>>> Thanks to all of you!
>>>
>>>
>

[mdb-dev] [patch] exporting indexes

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

Here is a more intrusive patch, mostly for indexes:

* I was fed up with adding code both in util/mdb-schema.c and gmdb2/schema.c. These were mostly duplicated code.
So I moved the common parts in libmdb/backend.c, that means a new function called "print_schema" that will call the relevant code.

* Indexed now are generated for postgres backend: normal ones, unique ones, and primary keys.

* Fixed a bug in where all the foreign keys were generated when you export only one table (added a parameter to mdb_get_relationships).

* Now using PATH_MAX and MDB_MAX_OBJ_NAME macro for sizes of constants in gmdb2/schema.c, rather than hardcoded values 256/100.


Question:
Do we want to keep all the "sanitize" stuff?? We now have proper escaping for all backends, I think.

Re: [mdb-dev] mdbtools dll on Windows

[Leonardo F. <leo...@gm...>]

Thanks Alexander, ok,
I'm starting trying to dump the database with mdbtools now;
if anyone has some suggest for me, it is welcome!

Thanks!!

2011/2/8 Alexander Lehner <le...@ed...>

>
>
> Hi Leonardo,
>
> I don't know about such a DLL, but I know that accessing a native C-library
> (dll) from C# is quite a pain.
> Depending on what you are planning to do, I would rather suggest to write
> the database-related code in C, using mdbtools and dump the result in a
> simple plaintext file which then can be read from C#.
>
> A.
>
>
>
> On Tue, 8 Feb 2011, Leonardo Francesconi wrote:
>
>  Dear developers,
>> I'm an Italian Computer Science student (so excuse me for my English) and
>> I'm working to access and query some .mdb database with Visual Studio C#.
>> Unfortunately to handle these database I need to be part of the workgroup
>> described into a .mdw file, and I don't have any password to do that.
>> Of course mdbtools can access them, so I'm wondering if there exists a
>> collection of .dll with the mdbtools algorithms to be added to my C#
>> project, and in that case, how could I use them.
>>
>> Thanks to all of you!
>>
>>

Re: [mdb-dev] mdbtools dll on Windows

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

Hi Leonardo,

I don't know about such a DLL, but I know that accessing a native 
C-library (dll) from C# is quite a pain.
Depending on what you are planning to do, I would rather suggest to write 
the database-related code in C, using mdbtools and dump the result in a 
simple plaintext file which then can be read from C#.

A.


On Tue, 8 Feb 2011, Leonardo Francesconi wrote:

> Dear developers,
> I'm an Italian Computer Science student (so excuse me for my English) and
> I'm working to access and query some .mdb database with Visual Studio C#.
> Unfortunately to handle these database I need to be part of the workgroup
> described into a .mdw file, and I don't have any password to do that.
> Of course mdbtools can access them, so I'm wondering if there exists a
> collection of .dll with the mdbtools algorithms to be added to my C#
> project, and in that case, how could I use them.
>
> Thanks to all of you!
>

[mdb-dev] mdbtools dll on Windows

[Leonardo F. <leo...@gm...>]

Dear developers,
I'm an Italian Computer Science student (so excuse me for my English) and
I'm working to access and query some .mdb database with Visual Studio C#.
Unfortunately to handle these database I need to be part of the workgroup
described into a .mdw file, and I don't have any password to do that.
Of course mdbtools can access them, so I'm wondering if there exists a
collection of .dll with the mdbtools algorithms to be added to my C#
project, and in that case, how could I use them.

Thanks to all of you!

Re: [mdb-dev] [patch] export OLE fields

[Brian B. <br...@br...>]

Hi Nirgal,

You are spot about why we are fprintf()'ing to stdout.  It would have
made it easier to search/replace and do something useful with the
output later.  The OLE stuff was all very nascent and I was still
trying to figure out how to make sense of it, thus the state it was
in.

Quite a few patches from you in the past two days.  I'm going to try
to sort through them tonight if I can (been fighting a nasty cold),
and if not early this week definitely.

Brian

2011/2/7 Nirgal Vourgère <con...@ni...>:
> On Monday 07 February 2011 22:12:58 Thomas Adam wrote:
>> Why not just printf() as it will print to STDOUT anyway.  Same comment for
>> the other occurances it happens for in this patch.
>
> I simply kept the ... strange ... existing convention for the code around.
> Maybe one day this may write to a real file. Just maybe...
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
>

[mdb-dev] [tip] Invalid dates in mdb-export for postgres

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

Hi again

I've been annoyed for a long time with some dates being not supported by postgresql, or so I though. I'm talking about dates before 1000 AD. I though postgres refused them. But there is a work around: You simply have to have a 4 digit year. For example 201-01-01T00:00:00 will fail, but 0201-01-01T00:00:00 is ok. Unfortunatly, I was not able to find a strftime format for this.
So now, I'm using:

mdb-export -D "{postgresdate}%Y-%m-%d %H:%M:%S" "$MDB" "$table" | sed -re 's/\{postgresdate\}([0-9]{2})-/00\1-/g' | sed -re 's/\{postgresdate\}([0-9]{3})-/0\1-/g' | sed -re 's/\{postgresdate\}//g

Cheers

Re: [mdb-dev] [patch] export OLE fields

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

On Monday 07 February 2011 22:12:58 Thomas Adam wrote:
> Why not just printf() as it will print to STDOUT anyway.  Same comment for
> the other occurances it happens for in this patch.

I simply kept the ... strange ... existing convention for the code around.
Maybe one day this may write to a real file. Just maybe...

[mdb-dev] [patch] kkd / mdb-props

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

... and here's a little clean up for kkd / mdb-props. It applies to github repository.

mdb-props used to output a lot of debug messages. This is because we are using #ifdef MDB_DEBUG rather than #if MDB_DEBUG. Note that mdbtools.h #defines MDB_DEBUG 0.

mdb-props used to want a 3rd argument, the name of the *MSysObject* column. It now defaults to "LvProp", that is the column containing the most useful information.

I also fixed a few changes in the obsolete file prkkd.c. It's really not usefull, now that mdb-props works ok. But since I did it, you can merge nevertheless.

Cheers

[mdb-dev] [patch] export OLE fields

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

Hello

When using mdb-export on OLE fields, they are processed as text fields.
This results in several problems:
- Output stops as soon as a 0 si found
- Non ascii characters are output in a weird way, sometimes resulting in a broken csv file.

Attached is a patch.
I had to add the length in print_col function, because we can't use the sentinel for strings containing \0.
You can try on MsSysObjects tables: You'll get more information in the LvProp table, kdd numbers for example...

[mdb-dev] Write Support - Port or write?

[Houston, D. A Sr C. M. U. O. <dio...@us...>]

Hi all,

Once again, I'm looking at this project to add to the GDAL project to import/export files in a MDB compatible format.  In desiring to make it as open as possible, I don't intend to use Jet.

As we all know, write support is currently only partially supported in the source.  I am aware of another MDB library which does support writing called Jackcess, http://jackcess.sourceforge.net/ .  I am neither proficient in Java, nor highly knowledgeable on the Jet database format (although I did use to work in the group).  It seems like there are two main options:

- Figure out the write code, possibly using Jackcess and incorporate it into MDB Tools

- Port Jackcess to C++

Based on collective experience of the group, does anyone have any analysis or recommendations of what would be easier?  I looked over the Java source and it doesn't seem too complicated, but I don't know what I don't know about porting Java.  On the other hand, I don't really know where to begin on adding write support to MDB Tools, but I am highly comfortable with C/C++.

Thanks in advance for any wisdom you can impart…

Dion

[mdb-dev] [patch] problem with floats (v2)

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

Looking at the file.c, I noticed we assume access floats are always 4 bytes, and double always 8. So it's not relevant to test what kind of float the local machine uses.
I think we can hard code the precision:
float: 24 bits mantice -> 8 characters
double: 53 bits mantice -> 16 characters
Keeping the same idea than bellow, attached is a revised and simplified patch. No more trouble with libm also.


On Sunday 06 February 2011 17:47:21 Nirgal Vourgère wrote:
> Hello
> 
> I have a problem introduced by the fix of http://bugs.debian.org/220403
> 
> Here was a part of the patch:
> Index: mdbtools-0.6pre1/src/libmdb/data.c
> ===================================================================
> --- mdbtools-0.6pre1.orig/src/libmdb/data.c
> +++ mdbtools-0.6pre1/src/libmdb/data.c
> @@ -857,7 +857,7 @@
>         break;
>         case MDB_FLOAT:
>             tf = mdb_get_single(buf, start);
> -           text = g_strdup_printf("%.*e",
> +           text = g_strdup_printf("%.*f",
>                 FLT_DIG - floor_log10(tf,1) - 1, tf);
>         break;
>         case MDB_DOUBLE:
> 
> 
> Rebuilding with MDB_DEBUG, I have this kind of output for prdata:
> 055b  00 24 64 46 
> column 1 is 1.5e+04
> 
> Python tells me the output should be
> struct.unpack('f', '\x00\x24\x64\x46')
> 14601.0
> 
> When reverting the patch, I get from prdata:
> 055b  00 24 64 46
> column 1 is 14601.0
> 
> I tried 1e-7 that was supposed not to work, and was the reason the patch was introduced. I have no problem:
> column 1 is 0.000000100000
> 
> 
> 
> You'll notice the unusual syntax "%.*f" that takes 2 arguments: the precision then the value.
> 
> I don't feel confortable exporting floats such as 1e-37 as a very long string, so I suggest we keep the 'e' format.
> 
> The precision however is wrong.
> I was about to use FLT_DIG, but it is repported buggy. :/
> Here, I have FLT_MANT_DIG==24 bits, meaning the maximum number without the exponent is 2^24=16777216
> The number of digits in a decimal representation is ceil(log10(16777216))=8
> The number of characters before the dot is not taken into account when specifying the precision
> printf("%.*e\n", 3, 1.23456789) -> 1.235e+00
> So that leave us with an extra number character. I assume this is usefull going arround roundings.
> 
> Does that sound ok?
> 
> Attached is the patch.
> I added some '-lm' for the linker to find the builtin math functions. I'm not very familiar with automake, you'd better check I did it right.
> 
> 
> Or maybe the original patch should just be reverted (for both MDB_FLOAT and MDB_DOUBLE)...

[mdb-dev] [patch] problem with floats

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

Hello

I have a problem introduced by the fix of http://bugs.debian.org/220403

Here was a part of the patch:
Index: mdbtools-0.6pre1/src/libmdb/data.c
===================================================================
--- mdbtools-0.6pre1.orig/src/libmdb/data.c
+++ mdbtools-0.6pre1/src/libmdb/data.c
@@ -857,7 +857,7 @@
        break;
        case MDB_FLOAT:
            tf = mdb_get_single(buf, start);
-           text = g_strdup_printf("%.*e",
+           text = g_strdup_printf("%.*f",
                FLT_DIG - floor_log10(tf,1) - 1, tf);
        break;
        case MDB_DOUBLE:


Rebuilding with MDB_DEBUG, I have this kind of output for prdata:
055b  00 24 64 46 
column 1 is 1.5e+04

Python tells me the output should be
struct.unpack('f', '\x00\x24\x64\x46')
14601.0

When reverting the patch, I get from prdata:
055b  00 24 64 46
column 1 is 14601.0

I tried 1e-7 that was supposed not to work, and was the reason the patch was introduced. I have no problem:
column 1 is 0.000000100000



You'll notice the unusual syntax "%.*f" that takes 2 arguments: the precision then the value.

I don't feel confortable exporting floats such as 1e-37 as a very long string, so I suggest we keep the 'e' format.

The precision however is wrong.
I was about to use FLT_DIG, but it is repported buggy. :/
Here, I have FLT_MANT_DIG==24 bits, meaning the maximum number without the exponent is 2^24=16777216
The number of digits in a decimal representation is ceil(log10(16777216))=8
The number of characters before the dot is not taken into account when specifying the precision
printf("%.*e\n", 3, 1.23456789) -> 1.235e+00
So that leave us with an extra number character. I assume this is usefull going arround roundings.

Does that sound ok?

Attached is the patch.
I added some '-lm' for the linker to find the builtin math functions. I'm not very familiar with automake, you'd better check I did it right.


Or maybe the original patch should just be reverted (for both MDB_FLOAT and MDB_DOUBLE)...

[mdb-dev] [patch] indexes

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

Hello MDB folks.

I'm trying to have mdb-schema export the indexes.

I hit a couple of problems in mdb_read_indices:

1/ When parsing table definition page, we expect index->index_num to be growing from 0 to table->num_real_idxs.
This is not allways true.
I think you can reproduce the problem by deleting some indexes.
This resulted in wrong columns beeing associated with indexes.
Include is a patch that will find the index with matching index_num.

2/ When associating the columns with the index, we were assuming the column position in table->columns is the same than col->col_num
This is not allways true.
I think you can reproduce this by deleting some columns.
This resulted in segment violation.
The patch include a loop to find the column with the correct col_num.

Also, I moved the test about pidx being null and num_real_idxs beeing patched, up in the logic. I still don't really like it, but it's a bit better IMHO.

Finally, I updated the HACKING file, and I left some of my debug messages commented out.


I suggest you merge the indexes patch, for the github repository.


Included is also another patch for mdb-schema to output the index creation section. This is work in progress, and I suggest you don't merge it yet, because it wrongfully assumes you are using postgres backend:
It will generate this kind of lines:
-- CREATE ANY INDEXES ...
CREATE INDEX "tTelecomsDescription" ON "tTelecom" ("sDescription");
CREATE UNIQUE INDEX "tAuthorisationActionsDescription" ON "tAuthorisationAction" ("sDescription");
ALTER TABLE "tGeneralDefinition" ADD CONSTRAINT "tGeneralDefinitionprimarykey" PRIMARY KEY ("iDefinitionGroupID", "iDatabaseID");

Could any one point to me the different index syntaxes for our supported backends?

[mdb-dev] Bug in copying MDB_NUMERIC fields

[Jakob E. <jab...@gm...>]

There is a serious bug in libmdb, where the first two digits after the comma are deleted in numeric fields.

The problem is in the file "src/libmdb/data.c" in function "mdb_num_to_string" around line 718:

The line is supposed to be:
memmove(text+prec-scale+1, text+prec-scale, scale+1); //RIGHT

And not:
memmove(text+prec-scale, text+prec-scale+1, scale+1); //WRONG

WORKAROUND: use DOUBLE rather than NUMERIC fields

best regards,
Jakob Egger

Re: [mdb-dev] [PATCH] Replace .cvsignore files with a single .gitignore file

[Brian B. <br...@br...>]

Applied.

2010/9/24 Jeff Smith <why...@ya...>:
> ---
> As I read it, the CVS repo is entirely historical at this point.
> This is yet one more step in the direction of git development.
>
>  .cvsignore                      |   18 -----------
>  .gitignore                      |   60 +++++++++++++++++++++++++++++++++++++++
>  doc/.cvsignore                  |    7 ----
>  doc/reference/libmdb/.cvsignore |    2 -
>  include/.cvsignore              |    6 ----
>  src/.cvsignore                  |    2 -
>  src/extras/.cvsignore           |    5 ---
>  src/gmdb/.cvsignore             |    5 ---
>  src/gmdb2/.cvsignore            |    5 ---
>  src/gmdb2/gladefiles/.cvsignore |    3 --
>  src/gmdb2/help/.cvsignore       |    2 -
>  src/gmdb2/help/C/.cvsignore     |    3 --
>  src/gmdb2/pixmaps/.cvsignore    |    2 -
>  src/libmdb/.cvsignore           |    6 ----
>  src/odbc/.cvsignore             |    7 ----
>  src/sql/.cvsignore              |    9 ------
>  src/util/.cvsignore             |   23 ---------------
>  17 files changed, 60 insertions(+), 105 deletions(-)
>  delete mode 100644 .cvsignore
>  create mode 100644 .gitignore
>  delete mode 100644 doc/.cvsignore
>  delete mode 100644 doc/reference/libmdb/.cvsignore
>  delete mode 100644 include/.cvsignore
>  delete mode 100644 src/.cvsignore
>  delete mode 100644 src/extras/.cvsignore
>  delete mode 100644 src/gmdb/.cvsignore
>  delete mode 100644 src/gmdb2/.cvsignore
>  delete mode 100644 src/gmdb2/gladefiles/.cvsignore
>  delete mode 100644 src/gmdb2/help/.cvsignore
>  delete mode 100644 src/gmdb2/help/C/.cvsignore
>  delete mode 100644 src/gmdb2/pixmaps/.cvsignore
>  delete mode 100644 src/libmdb/.cvsignore
>  delete mode 100644 src/odbc/.cvsignore
>  delete mode 100644 src/sql/.cvsignore
>  delete mode 100644 src/util/.cvsignore
>
> diff --git a/.cvsignore b/.cvsignore
> deleted file mode 100644
> index bea2c5c..0000000
> --- a/.cvsignore
> +++ /dev/null
> @@ -1,18 +0,0 @@
> -Makefile
> -Makefile.in
> -aclocal.m4
> -configure
> -config.log
> -config.status
> -autom4te-*.cache
> -config.guess
> -config.sub
> -libtool
> -ltmain.sh
> -mdbtools.spec
> -autom4te.cache
> -libmdb.pc
> -libmdbsql.pc
> -missing
> -install-sh
> -depcomp
> diff --git a/.gitignore b/.gitignore
> new file mode 100644
> index 0000000..0eef432
> --- /dev/null
> +++ b/.gitignore
> @@ -0,0 +1,60 @@
> +Makefile
> +Makefile.in
> +*.o
> +*.lo
> +*.la
> +*.1
> +.deps/
> +.libs/
> +
> +aclocal.m4
> +config.guess
> +config.log
> +config.status
> +config.sub
> +configure
> +depcomp
> +install-sh
> +libmdb.pc
> +libmdbsql.pc
> +libtool
> +ltmain.sh
> +mdbtools.spec
> +missing
> +ylwrap
> +
> +autom4te.cache/
> +
> +include/config.h
> +include/config.h.in
> +include/mdbver.h
> +include/stamp-h1
> +
> +src/extras/mdb-hexdump
> +src/gmdb/gmdb
> +src/gmdb2/gmdb2
> +src/gmdb2/gladefiles/*.gladep
> +src/gmdb2/help/C/omf_timestamp
> +src/odbc/unittest
> +src/sql/lexer.c
> +src/sql/parser.c
> +src/sql/parser.h
> +src/util/mdb-array
> +src/util/mdb-check
> +src/util/mdb-export
> +src/util/mdb-header
> +src/util/mdb-import
> +src/util/mdb-parsecsv
> +src/util/mdb-prop
> +src/util/mdb-schema
> +src/util/mdb-sql
> +src/util/mdb-tables
> +src/util/mdb-ver
> +src/util/prcat
> +src/util/prdata
> +src/util/prdump
> +src/util/prindex
> +src/util/prkkd
> +src/util/prole
> +src/util/prtable
> +src/util/updrow
> diff --git a/doc/.cvsignore b/doc/.cvsignore
> deleted file mode 100644
> index 296fff9..0000000
> --- a/doc/.cvsignore
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -Makefile
> -Makefile.in
> -mdb-sql.1
> -mdb-ver.1
> -mdb-schema.1
> -mdb-export.1
> -mdb-tables.1
> diff --git a/doc/reference/libmdb/.cvsignore b/doc/reference/libmdb/.cvsignore
> deleted file mode 100644
> index 282522d..0000000
> --- a/doc/reference/libmdb/.cvsignore
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -Makefile
> -Makefile.in
> diff --git a/include/.cvsignore b/include/.cvsignore
> deleted file mode 100644
> index 5b0e80e..0000000
> --- a/include/.cvsignore
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -Makefile
> -Makefile.in
> -config.h
> -config.h.in
> -stamp-h1
> -mdbver.h
> diff --git a/src/.cvsignore b/src/.cvsignore
> deleted file mode 100644
> index 282522d..0000000
> --- a/src/.cvsignore
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -Makefile
> -Makefile.in
> diff --git a/src/extras/.cvsignore b/src/extras/.cvsignore
> deleted file mode 100644
> index 8f4d934..0000000
> --- a/src/extras/.cvsignore
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -Makefile
> -Makefile.in
> -.deps
> -.libs
> -mdb-hexdump
> diff --git a/src/gmdb/.cvsignore b/src/gmdb/.cvsignore
> deleted file mode 100644
> index a030779..0000000
> --- a/src/gmdb/.cvsignore
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -Makefile
> -Makefile.in
> -.deps
> -.libs
> -gmdb
> diff --git a/src/gmdb2/.cvsignore b/src/gmdb2/.cvsignore
> deleted file mode 100644
> index 2da21c1..0000000
> --- a/src/gmdb2/.cvsignore
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -Makefile
> -Makefile.in
> -.deps
> -.libs
> -gmdb2
> diff --git a/src/gmdb2/gladefiles/.cvsignore b/src/gmdb2/gladefiles/.cvsignore
> deleted file mode 100644
> index 5a89b9b..0000000
> --- a/src/gmdb2/gladefiles/.cvsignore
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -*.gladep
> -Makefile.in
> -Makefile
> diff --git a/src/gmdb2/help/.cvsignore b/src/gmdb2/help/.cvsignore
> deleted file mode 100644
> index 3dda729..0000000
> --- a/src/gmdb2/help/.cvsignore
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -Makefile.in
> -Makefile
> diff --git a/src/gmdb2/help/C/.cvsignore b/src/gmdb2/help/C/.cvsignore
> deleted file mode 100644
> index 035f4a5..0000000
> --- a/src/gmdb2/help/C/.cvsignore
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -Makefile.in
> -Makefile
> -omf_timestamp
> diff --git a/src/gmdb2/pixmaps/.cvsignore b/src/gmdb2/pixmaps/.cvsignore
> deleted file mode 100644
> index 3dda729..0000000
> --- a/src/gmdb2/pixmaps/.cvsignore
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -Makefile.in
> -Makefile
> diff --git a/src/libmdb/.cvsignore b/src/libmdb/.cvsignore
> deleted file mode 100644
> index 6e5ca7e..0000000
> --- a/src/libmdb/.cvsignore
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -Makefile
> -Makefile.in
> -.deps
> -.libs
> -*.lo
> -*.la
> diff --git a/src/odbc/.cvsignore b/src/odbc/.cvsignore
> deleted file mode 100644
> index 70e81af..0000000
> --- a/src/odbc/.cvsignore
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -Makefile
> -Makefile.in
> -.deps
> -.libs
> -*.lo
> -*.la
> -unittest
> diff --git a/src/sql/.cvsignore b/src/sql/.cvsignore
> deleted file mode 100644
> index 243aa08..0000000
> --- a/src/sql/.cvsignore
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -Makefile
> -Makefile.in
> -.deps
> -.libs
> -parser.c
> -lexer.c
> -parser.h
> -*.lo
> -*.la
> diff --git a/src/util/.cvsignore b/src/util/.cvsignore
> deleted file mode 100644
> index 0322d46..0000000
> --- a/src/util/.cvsignore
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -Makefile
> -Makefile.in
> -.deps
> -.libs
> -mdb-array
> -mdb-export
> -mdb-header
> -mdb-parsecsv
> -mdb-schema
> -mdb-sql
> -mdb-tables
> -mdb-ver
> -mdb-check
> -mdb-import
> -mdb-prop
> -prcat
> -prdata
> -prdump
> -prkkd
> -prtable
> -prole
> -prindex
> -updrow
> --
> 1.7.2.3
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
>

[mdb-dev] [PATCH 1/2] Normalized whitespace in Makefile.am, mdb-export.c, and mdb-schema.c.

[David F. <mdb...@me...>]

Signed-off-by: David Favro <mdb...@me...>
---
 src/util/Makefile.am  |    6 +++---
 src/util/mdb-export.c |   24 ++++++++++++------------
 src/util/mdb-schema.c |   39 +++++++++++++++++++--------------------
 3 files changed, 34 insertions(+), 35 deletions(-)

diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index 6e9e413..c872aec 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -1,9 +1,9 @@
-bin_PROGRAMS	=	mdb-export mdb-array mdb-schema mdb-tables mdb-parsecsv mdb-header mdb-sql mdb-ver mdb-prop 
+bin_PROGRAMS	=	mdb-export mdb-array mdb-schema mdb-tables mdb-parsecsv mdb-header mdb-sql mdb-ver mdb-prop
 noinst_PROGRAMS = mdb-import prtable prcat prdata prkkd prdump prole updrow prindex
-LIBS	=	$(GLIB_LIBS) @LIBS@ @LEXLIB@ 
+LIBS	=	$(GLIB_LIBS) @LIBS@ @LEXLIB@
 DEFS = @DEFS@ -DLOCALEDIR=\"$(localedir)\"
 AM_CPPFLAGS	=	-I$(top_srcdir)/include $(GLIB_CFLAGS)
-LDADD	=	../libmdb/libmdb.la 
+LDADD	=	../libmdb/libmdb.la
 if SQL
 mdb_sql_LDADD = ../libmdb/libmdb.la ../sql/libmdbsql.la $(LIBREADLINE)
 endif
diff --git a/src/util/mdb-export.c b/src/util/mdb-export.c
index a484a01..8aa5290 100644
--- a/src/util/mdb-export.c
+++ b/src/util/mdb-export.c
@@ -2,7 +2,7 @@
  * Copyright (C) 2000 Brian Bruns
  *
  *
- * This library is free software; you can redistribute it and/or 
+ * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
  * License as published by the Free Software Foundation; either
  * version 2 of the License, or (at your option) any later version.
@@ -62,7 +62,7 @@ main(int argc, char **argv)
 	MdbTableDef *table;
 	MdbColumn *col;
 	char **bound_values;
-	int  *bound_lens; 
+	int  *bound_lens;
 	char *delimiter = NULL;
 	char *row_delimiter = NULL;
 	char *quote_char = NULL;
@@ -116,10 +116,10 @@ main(int argc, char **argv)
 	if (!row_delimiter) {
 		row_delimiter = (char *) g_strdup("\n");
 	}
-	
-	/* 
-	** optind is now the position of the first non-option arg, 
-	** see getopt(3) 
+
+	/*
+	** optind is now the position of the first non-option arg,
+	** see getopt(3)
 	*/
 	if (argc-optind < 2) {
 		fprintf(stderr,"Usage: %s [options] <file> <table>\n",argv[0]);
@@ -165,7 +165,7 @@ main(int argc, char **argv)
 
 	mdb_read_columns(table);
 	mdb_rewind_table(table);
-	
+
 	bound_values = (char **) g_malloc(table->num_cols * sizeof(char *));
 	bound_lens = (int *) g_malloc(table->num_cols * sizeof(int));
 	for (j=0;j<table->num_cols;j++) {
@@ -192,7 +192,7 @@ main(int argc, char **argv)
 				if (j>0) fprintf(stdout, ", ");
 				col=g_ptr_array_index(table->columns,j);
 				fprintf(stdout,"%s", sanitize_name(col->name,sanitize));
-			} 
+			}
 			fprintf(stdout, ") VALUES (");
 		}
 
@@ -238,15 +238,15 @@ static char *sanitize_name(char *str, int sanitize)
 
 	if (!sanitize)
 		return str;
-		
+
 	while (*str) {
 		*p = isalnum(*str) ? *str : '_';
 		p++;
 		str++;
 	}
-	
+
 	*p = 0;
-										
+
 	return namebuf;
 }
 
@@ -263,7 +263,7 @@ static char *escapes(char *s)
 			case 't': *t++='\t'; break;
 			case 'r': *t++='\r'; break;
 			default: *t++='\\'; *t++=*s; break;
-			}	
+			}
 			encode=0;
 		} else if (*s=='\\') {
 			encode=1;
diff --git a/src/util/mdb-schema.c b/src/util/mdb-schema.c
index 012bb2f..b142711 100644
--- a/src/util/mdb-schema.c
+++ b/src/util/mdb-schema.c
@@ -61,7 +61,7 @@ main (int argc, char **argv)
 			break;
 		}
 	}
- 
+
 	mdb_init();
 
 	/* open the database */
@@ -81,7 +81,7 @@ main (int argc, char **argv)
 	}
 
 	/* read the catalog */
- 	if (!mdb_read_catalog (mdb, MDB_TABLE)) {
+	if (!mdb_read_catalog (mdb, MDB_TABLE)) {
 		fprintf(stderr,"File does not appear to be an Access database\n");
 		exit(1);
 	}
@@ -99,7 +99,7 @@ main (int argc, char **argv)
 	for (i=0; i < mdb->num_catalog; i++) {
 		entry = g_ptr_array_index (mdb->catalog, i);
 		if (entry->object_type == MDB_TABLE) {
-			if ((tabname && !strcmp(entry->object_name, tabname)) 
+			if ((tabname && !strcmp(entry->object_name, tabname))
 			 || (!tabname && mdb_is_user_table(entry))) {
 				generate_table_schema(entry, namespace, s);
 			}
@@ -112,8 +112,8 @@ main (int argc, char **argv)
 	while ((the_relation=mdb_get_relationships(mdb)) != NULL) {
 		fprintf(stdout,"%s\n",the_relation);
 		g_free(the_relation);
-	}            
- 
+	}
+
 	g_free(namespace);
 	g_free(tabname);
 	mdb_close (mdb);
@@ -137,7 +137,7 @@ generate_table_schema(MdbCatalogEntry *entry, char *namespace, int sanitize)
 	fprintf (stdout, "CREATE TABLE %s%s\n", (namespace) ? namespace : "",
 		sanitize_name(entry->object_name, sanitize));
 	fprintf (stdout, " (\n");
-	       	       
+
 	table = mdb_read_table (entry);
 
 	/* get the columns */
@@ -147,20 +147,20 @@ generate_table_schema(MdbCatalogEntry *entry, char *namespace, int sanitize)
 
 	for (i = 0; i < table->num_cols; i++) {
 		col = g_ptr_array_index (table->columns, i);
-		   
-		fprintf (stdout, "\t%s\t\t\t%s", sanitize_name(col->name,sanitize), 
+
+		fprintf (stdout, "\t%s\t\t\t%s", sanitize_name(col->name,sanitize),
 		mdb_get_coltype_string (mdb->default_backend, col->col_type));
-		   
-		if (mdb_coltype_takes_length(mdb->default_backend, 
+
+		if (mdb_coltype_takes_length(mdb->default_backend,
 			col->col_type)) {
 
-			/* more portable version from DW patch */	
-			if (col->col_size == 0) 
-	    			fprintf (stdout, " (255)");
-			else 
-	    			fprintf (stdout, " (%d)", col->col_size);
+			/* more portable version from DW patch */
+			if (col->col_size == 0)
+				fprintf (stdout, " (255)");
+			else
+				fprintf (stdout, " (%d)", col->col_size);
 		}
-		   
+
 		if (i < table->num_cols - 1)
 			fprintf (stdout, ", \n");
 		else
@@ -181,15 +181,14 @@ static char *sanitize_name(char *str, int sanitize)
 
 	if (!sanitize)
 		return str;
-		
+
 	while (*str) {
 		*p = isalnum(*str) ? *str : '_';
 		p++;
 		str++;
 	}
-	
+
 	*p = 0;
-										
+
 	return namebuf;
 }
-
-- 
1.7.0.4