mdbtools-dev

[mdb-dev] handling for data rows

[Brian B. <ca...@um...>]

Hi all,

I just added some code for actually printing data.  It's still really
rough and I have a patch yet to be integrated, but it does really work on
my data :-).  You can check it out of CVS if interested.

Over the weekend, I'll be modularizing the data.c file a bit more (it's
one long function at the moment) and hopefully making a way to allow
applications linking to libmdb a way to bind the data back.

Once these pieces are in place, I think we can really start doing
something useful with this stuff!

Cheers,

Brian

Re: [mdb-dev] table.c

[Brian B. <ca...@um...>]

The main reason is that I wanted to play around with exporting to Sybase
:-)

Most of the code at this point is just working out the structure of the
mdb files.  I don't have my heart set on any of it...in fact I've been
mulling over it, trying to decide on better ways to do things.  I'm not
real comfortable with the GArrays for instance, but on the other hand
reading the catalog once to get a count and then allocating it, and
rereading seems wasteful. Also, the KKD properties (design view stuff) its
highly variable, so a hash table seemed appropriate.

But, some of it strikes me as not The Right Way(tm) so I've been a bit
hesitant to cast much in stone yet.  Perhaps, I'm worrying over nothing!

As far as exporting schema, my current plan is to have a utility such as
'export-schema' and take switches like:

$ ./export-schema --target=sybase -f mydb.mdb -o mydb.sql

so you can specify different target engines.  Maybe we could even do it in
a plugin style using dlopen() and friends...that way different database
backends could be added apart from the mainline code.

Brian

On Wed, 8 Mar 2000, Carl Seutter wrote:

> I finally got a chance to start looking at some of the code today.
> Looking good.  However, while I was reading the comments in table.c the
> question was raised about how to make the column_types generic.
> Therefore, why not print out the Access datatype.
> 
> Then, have different modules for the target database.  Each module would
> then be responsible for the necessary tasks specific to that target.
> 
> 
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> http://lists.sourceforge.net/mailman/listinfo/mdbtools-dev
> 

[mdb-dev] table.c

[Carl S. <cgs...@wo...>]

I finally got a chance to start looking at some of the code today.
Looking good.  However, while I was reading the comments in table.c the
question was raised about how to make the column_types generic.
Therefore, why not print out the Access datatype.

Then, have different modules for the target database.  Each module would
then be responsible for the necessary tasks specific to that target.

[mdb-dev] Build problem with 0.002

[Brian B. <ca...@um...>]

There was a build problem with 0.002, I've put put a new release (0.003)
out to fix it.

Brian

[mdb-dev] Test Message

[Brian B. <ca...@um...>]

Welcome to the mdbtools-dev list.  This list is for the discussion of the
the MDB file format and its implementation in the MDB Tools project.

For more info about MDB Tools, see http://mdbtools.sourceforge.net

Brian