mdbtools-dev

[mdb-dev] mdbtools 0.6pre1 crash

[John C. <jf...@MI...>]

I built mdbtools 0.6pre1 with the Sun C compiler in 64 bit mode on a
SPARC running Solaris 8.  I have a file which makes mdb-export crash.
Fetch and unpack <http://www.mhd.state.ma.us/planning/RoadInv_GDB.zip>
(unpacks to over 300 MB).  Run
% mdb-export RoadInventory.mdb RoadInventory
mdb-export spews a series of garbage lines then dumps core.

The proximate cause of the crash is an array overflow of the
/text/ array in mdb_col_to_string because argument /size/ exceeds
MDB_BIND_SIZE, but I think the program went wrong long before that.

[mdb-dev] Compiling mdb-tools 0.6

[<Mic...@t-...>]

Hi all,

Some days ago I installed mdbtools-0.5-1.i386.rpm and 
mdbtools-gui-0.5-1.i368.rpm on SuSE 9.1 (I had very good experiences on SuSE 
9.0) and noticed that 
with locale de_DE.UTF-8 there is a problem. I could not export data with 
special characters correctly from a mdb-file (the special characters all 
disappeared). 
I then thought it could be a good idea to try 
mdbtools-0.6pre1. I downloaded, configured and compiled. First I tried to 
install with checkinstall but I got the message:
error: Failed dependencies:
        libmdb.0 is needed by mdbtools-0.6.pre1-1
        libmdbsql.0 is needes by mdbtools-0.6pre1-1
Therefore I tried make install but when I try mdb-export I got an error 
message:
mdb-export: error while loading shared libraries: libmdb.0: cannot open shared 
object file: No such file or directory. I am afraid I don't understand that  
because I found libmdb.0 (a link to libmdb.0.0.0) at /usr/local/lib (together 
with other files from mdbtools). It seems that make install installs it in a 
directory where the tool mdb-export doesn't expect it. 
What can I do? 
And: mdb-tools-0.6pre1-1 are able to export special characters on a 
de_DE.UTF-8 environment?

Thanks in advance.
Michael

[mdb-dev] [Fwd: [dba-dev] news for UTF-8 support for mdb files]

[Luciano M. W. <luc...@fr...>]

I would like to share with you also.


-----Forwarded Message-----
From: Luciano Miguel Wolf <luc...@fr...>
To: de...@db...
Subject: [dba-dev] news for UTF-8 support for mdb files
Date: Fri, 06 Aug 2004 15:21:51 -0300

Hi all,

I am working with Alexandre Horst to develop the mdb-sdbc-driver. We are
waiting Wind Li come back to take more guidelines in this task. In the
meantime we are preparing the MDBTools to work with UTF-8, and I believe
that we are close to have a stable version. 

In attachment you can see a screen shot of query editor OOo base
(SRC680_m40, cws_srx645_insight01). We've tested also in a version of
OOo without Base (SRC680_m48).

This query ran using MDBTools library with UTF-8 support. The query was
made with:

SELECT "供應商編號", "地址", "連絡人" FROM "供應商" "供應商" WHERE ( ( "連絡人" = '林小姐' ) )

We would like to contribute and share this development with community as
soon as possible, so we could receive bugs to fix them. In MDBTools
community we contribute with many patches fixing and enhancing the
library. Where should we upload our changes and future development?

Regards
Luciano Wolf
Alexandre Horst

________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev...@db...
For additional commands, e-mail: dev...@db...

[mdb-dev] mdb -> postgresql extractor

[jim b. <jim...@ho...>]

Hello,

I have recently been looking for a way to export some historic access data 
to postgresql. The mdbtools utilities have been great, but not ideal, so I 
used the libraries to write something that did the job, and thought it would 
be best to share.

It is called mdb_dump, and writes a dump much as pg_dump would, so you can:
mdb_dump db1.mdb | psql targetdatabase
to export all tables and their data to postgres.

The source can be found at:
http://dgym.homeunix.net/projects/mdb_dump.cc
Do what you want with it.

Thanks for the great set of tools and libraries,
dgym
a happy customer.

_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now!  
http://toolbar.msn.co.uk/

[mdb-dev] Bug 775047

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

The incorrect behavior noted in bug #775047 has been corrected sometime in the last year,
so this item may now be closed.  I confirmed the bug with a cvs extract from Jul 20, 2003
and confirmed the corrected behavior with a current cvs extract.  Someone with admin
access will have to be the one to close this bug (i.e. Brian).


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: [mdb-dev] [PATCH] JET4 shuffled columns

[Luciano M. W. <luc...@fr...>]

Ok. I am happy to help you. I will contribute with more paches. Now,
answering your question, you can credit this analysis and patch to me
and Alexandre Horst.

Our next effort will be with SQL parser UTF-8 support. Here in the
company, we are working to use mdbtools as a driver to import mdb files
inside OpenOffice.org. We are working with Wind Li, who developed the
first version of this driver.(*)

As it was discussed in mail list (de...@db...), we have 3
ways of development: 1) use mdbtools, improving its capabilities and
giving benefits to all the community; 2) use only part of mdbtools, and
improve the OOo parser; or 3) make a new native OOo driver for mdb
files. 

Is there any cvs branch which we could update and show to community our
development for OOo? Many patches are really annoying for people which
would like to have our last mdbtools version. So you could also merge
our changes in the main cvs branch/trunk as you wish.

Ciao,
Luciano and Alexandre

(*) link to his driver page -
http://dba.openoffice.org/drivers/mdb/index.html


On Tue, 2004-08-03 at 17:10, Jeff Smith wrote: 
> Your analysis is essentially correct.  However, in your patch you have duplicated the
> data item  referred to in HACKING as offset_V.  In MdbColumn, we have it as var_col_num,
> and you have it as variable_offset.  I am working on an improved patch for this, and will
> test it soon.  If all goes well, I may commit it tomorrow.  Who should I credit the
> analysis and patch to (if not just yourself)?
> 
>  -- Jeff Smith
> 
> --- Luciano Miguel Wolf <luc...@fr...> wrote:
> 
> > Hi all,
> > 
> > Since my last email I was analyzing a code part which envolves variable
> > columns and I noticed that some documented pieces of "Jet4 Table
> > Definition Block" were not being used. 
> > 
> > So to explain, the field "offset_V" allows to find the correct position
> > of variable columns, specially if there are deleted columns involved.
> > It's the index to "var_table[]", listed in "Jet4 Row Definition" of
> > HACKING guide.
> > 
> > My patch worked for the situation that I wrote in my last email. In
> > summary, if you have deleted columns, deleted data is not being
> > displayed and right data is in right column. Columns and data are not
> > being shuffled. And I think bug 669739 is resolved for Jet4.
> > 
> > Regards,
> > Luciano

Re: [mdb-dev] [PATCH] JET4 shuffled columns

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

Your analysis is essentially correct.  However, in your patch you have duplicated the
data item  referred to in HACKING as offset_V.  In MdbColumn, we have it as var_col_num,
and you have it as variable_offset.  I am working on an improved patch for this, and will
test it soon.  If all goes well, I may commit it tomorrow.  Who should I credit the
analysis and patch to (if not just yourself)?

 -- Jeff Smith

--- Luciano Miguel Wolf <luc...@fr...> wrote:

> Hi all,
> 
> Since my last email I was analyzing a code part which envolves variable
> columns and I noticed that some documented pieces of "Jet4 Table
> Definition Block" were not being used. 
> 
> So to explain, the field "offset_V" allows to find the correct position
> of variable columns, specially if there are deleted columns involved.
> It's the index to "var_table[]", listed in "Jet4 Row Definition" of
> HACKING guide.
> 
> My patch worked for the situation that I wrote in my last email. In
> summary, if you have deleted columns, deleted data is not being
> displayed and right data is in right column. Columns and data are not
> being shuffled. And I think bug 669739 is resolved for Jet4.
> 
> Regards,
> Luciano
> > Index: src/libmdb/table.c
> ===================================================================
> RCS file: /cvs/mdbtools/src/libmdb/table.c,v
> retrieving revision 1.1.2.1
> retrieving revision 1.4
> diff -u -r1.1.2.1 -r1.4
> --- src/libmdb/table.c	22 Jul 2004 13:35:50 -0000	1.1.2.1
> +++ src/libmdb/table.c	26 Jul 2004 21:15:06 -0000	1.4
> @@ -254,6 +254,9 @@
>  		// col_fixed_offset == 13 or 15
>  		pcol->is_fixed = col[fmt->col_fixed_offset] & 0x01 ? 1 : 0;
>  
> +		/* index to entry to a data which must be displayed */
> +		pcol->variable_offset = mdb_get_int16(col, fmt->tab_col_offset_var);
> +
>  		// col_fixed_offset == 13 or 15
>  		pcol->fixed_offset = mdb_get_int16(col, fmt->tab_col_offset_fixed);
>  		//fprintf(stdout,"fixed column offset %d\n",pcol->fixed_offset);
> Index: include/mdbtools.h
> ===================================================================
> RCS file: /cvs/mdbtools/include/mdbtools.h,v
> retrieving revision 1.1.2.1
> retrieving revision 1.5
> diff -u -r1.1.2.1 -r1.5
> --- include/mdbtools.h	22 Jul 2004 13:35:50 -0000	1.1.2.1
> +++ include/mdbtools.h	26 Jul 2004 21:15:06 -0000	1.5
> @@ -279,6 +279,7 @@
>  	int		col_scale;
>  	MdbProperties	*props;
>  	/* info needed for handling deleted/added columns */
> +	int 		variable_offset;
>  	int 		fixed_offset;
>  	int 		var_col_num;
>  	/* row_col_num is the row column number order, 
> Index: src/libmdb/write.c
> ===================================================================
> RCS file: /cvs/mdbtools/src/libmdb/write.c,v
> retrieving revision 1.1.4.1
> retrieving revision 1.2
> diff -u -r1.1.4.1 -r1.2
> --- src/libmdb/write.c	22 Jul 2004 13:35:50 -0000	1.1.4.1
> +++ src/libmdb/write.c	26 Jul 2004 18:45:02 -0000	1.2
> @@ -87,6 +87,7 @@
>  	}
>  	return 0;
>  }
> +
>  static int
>  mdb_crack_row4(MdbTableDef *table, int row_start, int row_end, MdbField *fields)
>  {
> @@ -96,14 +97,16 @@
>  	unsigned int i;
>  	int var_cols = 0, row_var_cols, fixed_cols = 0, row_fixed_cols, num_cols;
>  	int var_cols_found, fixed_cols_found, var_entry_pos;
> -	int col_start, next_col;
> +	int next_col, actual_col;
>  	unsigned char *nullmask;
>  	int bitmask_sz;
>  	int byte_num, bit_num;
>  	int eod, len; /* end of data */
>  	int real_offset = 0;
>  	int row_pos;
> -
> +	int eod_offset=0;
> +	int variable_offset=0;
> +	
>  	if (mdb_get_option(MDB_DEBUG_ROW)) {
>  		buffer_dump(mdb->pg_buf, row_start, row_end+1);
>  	}
> @@ -120,37 +123,48 @@
>  		byte_num = row_pos / 8;
>  		bit_num = row_pos % 8;
>  		/* logic on nulls is reverse, 1 is not null, 0 is null */
> -		fields[i].is_null = nullmask[byte_num] & 1 << bit_num ? 0 : 1;
> -		//printf("row_pos %d col %d is %s\n", row_pos, i, fields[i].is_null ? "null" : "not
> null");
> -	}
> +		fields[i].is_null = nullmask[byte_num] & (1 << bit_num) ? 0 : 1;
>  
> -	/* fields are ordered fixed then variable */
> -	for (i = 0; i < table->num_cols; i++) {
> -		col = g_ptr_array_index (table->columns, i);
> +		/* fields are ordered fixed then variable */
>  		if (mdb_is_fixed_col(col)) {
>  			fixed_cols++;
>  			fields[i].colnum = i;
>  			fields[i].siz = col->col_size;
>  			fields[i].is_fixed = 1;
>  		}
> -	}
> -	for (i = 0; i < table->num_cols; i++) {
> -		col = g_ptr_array_index (table->columns, i);
> -		if (!mdb_is_fixed_col(col)) {
> +		else{
>  			var_cols++;
>  			fields[i].colnum = i;
>  			fields[i].is_fixed = 0;
>  		}
>  	}
> -	row_var_cols = mdb_pg_get_int16(mdb, row_end - bitmask_sz - 1);
>  
>  	/* find the end of data pointer */
> -	eod = mdb_pg_get_int16(mdb, row_end - 3 - var_cols*2 - bitmask_sz);
> +	/*	number of variable columns 1 byte 
> +		bitmask size 1 to 8 bytes 
> +		variable columns 0 to 256 words (16 bits)*/
> +
> +	/* pay attention: some mdbs make use of those unknown bits and
> +	this is handled by the if below, to avoid erroneous eod and 
> +	row_var_cols values*/
> +	if(var_cols > 0)
> +	{
> +		/* modified to get just one byte from buffer, the other one is unknown. so do not
> read as a int */
> +		row_var_cols = ((unsigned char) mdb->pg_buf[row_end - bitmask_sz - 1]);
> +
> +		eod_offset= row_end - 1 - (row_var_cols * 2 + 2) - bitmask_sz;
> +		eod = mdb_pg_get_int16(mdb,eod_offset);
> +	}
> +	else
> +	{
> +		row_var_cols = 0;
> +		eod_offset = 0; 
> +		eod = 0;
> +	}	
>  
>  	/* actual cols on this row */
>  	fixed_cols_found = 0;
> -	var_cols_found = 0;
> -	row_fixed_cols = num_cols - row_var_cols;
> +	row_fixed_cols	 = num_cols - row_var_cols;
>  
>  	for (i=0;i<table->num_cols;i++) {
>  		col = g_ptr_array_index(table->columns,i);
> @@ -169,38 +183,39 @@
>  		}
>  	}
>  
> -	col_start = mdb_pg_get_int16(mdb, row_end - 3 - bitmask_sz);
> +	var_entry_pos 	= row_end - 3 - bitmask_sz;
> +	var_cols_found 	= 0;
>  
> +	/* now the var_cols are handled properly, using the index
> +	stored in TDEF page type (offset_V field)*/
>  	for (i=0;i<table->num_cols;i++) {
>  		col = g_ptr_array_index(table->columns,i);
>  		if (!mdb_is_fixed_col(col)) {
> -			var_cols_found++;
>  			if (var_cols_found <= row_var_cols)  {
> -				if (var_cols_found==row_var_cols)  {
> -					len=eod - col_start;
> -					//printf("len = %d eod %d col_start %d\n",len, eod, col_start);
> -				} else  {
> -					/* position of the var table 
> -				 	* entry for this column */
> -					var_entry_pos = 
> -						row_end - 
> -						bitmask_sz - 
> -						var_cols_found * 2 - 2 - 1;
> -					next_col = mdb_pg_get_int16(mdb, var_entry_pos);
> -					len = next_col - col_start;
> -				} /* if found==var_cols */
> -				//printf("len = %d eod %d col_start %d\n",len, eod, col_start);
> -				//printf("is_null %d\n",fields[i].is_null);
> -				fields[i].start = row_start + col_start;
> -				fields[i].value = &mdb->pg_buf[row_start +col_start];
> +				variable_offset=col->variable_offset;
> +				/* position of the var table 
> +					* entry for this column */
> +				if(variable_offset!=0xFF)
> +				{
> +					actual_col 	= mdb_pg_get_int16(mdb, var_entry_pos - variable_offset * 2);
> +					next_col 	= mdb_pg_get_int16(mdb, var_entry_pos - (variable_offset + 1) * 2);
> +				}
> +				else
> +				{
> +					actual_col 	= mdb_pg_get_int16(mdb, var_entry_pos - i * 2);
> +					next_col 	= mdb_pg_get_int16(mdb, var_entry_pos - (i + 1) * 2);
> +				}
> +				len = next_col - actual_col;
> +				fields[i].start = row_start + actual_col;
> +				fields[i].value = &mdb->pg_buf[fields[i].start];
>  				fields[i].siz = len;
> -				col_start += len;
>  			} else {
>  				fields[i].start = 0;
>  				fields[i].value = NULL;
>  				fields[i].siz = 0;
>  				fields[i].is_null = 1;
>  			}
> +			var_cols_found++;
>  		} /* if !fixed */
>  	} /* for */
>  
> 



		
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo 

[mdb-dev] [PATCH] JET4 shuffled columns

[Luciano M. W. <luc...@fr...>]

Hi all,

Since my last email I was analyzing a code part which envolves variable
columns and I noticed that some documented pieces of "Jet4 Table
Definition Block" were not being used. 

So to explain, the field "offset_V" allows to find the correct position
of variable columns, specially if there are deleted columns involved.
It's the index to "var_table[]", listed in "Jet4 Row Definition" of
HACKING guide.

My patch worked for the situation that I wrote in my last email. In
summary, if you have deleted columns, deleted data is not being
displayed and right data is in right column. Columns and data are not
being shuffled. And I think bug 669739 is resolved for Jet4.

Regards,
Luciano

[mdb-dev] [PATCH] fix initial jumps calculation for large rows

[David M. <mdb...@dm...>]

Hi Brian and list,

I've tracked down another nagging bug.  The attached patch is against 0.5 
plus all my patches, but it should apply just fine against CVS (just 
checked ;-).

The bug is that the code assumes the initial 'jump' value to be 0 or 1 
only.  But what happens if the data of the 'fixed' portion of the row is 
more than 512 bytes?  In this case the num_of_jumps and jumps_used should 
be 2 (or three for >=768 bytes etc.).

This fix just divides the number of bytes used by 256 (using integer 
rounding semantics) and initializes jumps that way.

This fixes reading a specific table for me.  The symptom was that the 
'variable length' columns would all be shifted by one, with the data in 
the wrong column, and with one column with no data.

Does this look like the correct fix?

David

Re: [mdb-dev] UTF-8 support

[Jochen R. <Joc...@db...>]

Ok, here comes my $LANG:

jochenr@lapjochen:~> echo $LANG
de_DE@euro

this is on a Linux, SUSE 8.2, obviously with German language configuration.

Jochen

Am Freitag, 30. Juli 2004 05:28 schrieb 
mdb...@li...:
> Message: 1
> To: why...@ya...
> Cc: luc...@fr..., mdb...@li...
> From: br...@br...
> Subject: Re: [mdb-dev] UTF-8 support
> Date: Tue, 27 Jul 2004 17:56:30 -0700 (PDT)
>
> I have it, but i need to tie up some loose ends.  I like the error
> handling in this patch better the my simple pass/fail.  On the other
> hand, there is no autoconf detection in the patch that I saw from my
> quick perusal.  Also, my patch sets up iconv once per handle, this one
>  seems to incur the overhead on each call (again from my quick look).
> Definately some good stuff in the patch though, and I'll try to merge
> the two and we'll be better for it.
>
> I'm still mulling over the problem of figuring out if the terminal
> supports UTF8 or not.  I'm leaning toward turning it on if $LANG
> contains the substring "utf8".  This works on RedHat 9/Fedora.  I'm
> very keen to hear what it is on other platforms.  Just,
>
> echo $LANG
>
> and post your results (along with the OS/distro you use of course) and
> if we get enough responses we should be able to determine the correct
> course of action.
>
> 669739 should be due to added/deleted/reordered columns and *should*
> be fixed. It works for all the test cases I have anyway.  If your
> willing to part with a database that still exhibits this behaviour,
> I'll certainly have a looksee.
>
> Brian
>
> On Tue, 27 Jul 2004 17:02:04 -0700 (PDT), Jeff Smith wrote:
> > If I am not mistaken, Brian already has some code for this (not that
>
> he
>
> > would not be able to use any of your work), but has not checked it in
> > due to some design decisions.  See message "Re: [mdb-dev] Old code"
> > from
> > July 17th.  I assume you are subscribed to the list.
> >
> > As for bug 669739, do you have test case to confirm this bug (in the
> > latest
> > pre-release)?  A lot has changed in the code since the bug was
> > reported and
> > it may be a dead issue.
> >
> >  -- Jeff S
> >
> > --- Luciano Miguel Wolf <luc...@fr...> wrote:
> > > Hi mdbtools developers,
> > >
> > > A few weeks ago I wrote to this list asking for UTF-8 support. In
>
> the
>
> > > mean time the company where I am working increased its interests in
> >
> > this
> >
> > > feature. I and co-worker (Alexandre Horst) have been working in
> >
> > source
> >
> > > code of libmdb and we have implemented the UTF-8 support. We have
> >
> > fixed
> >
> > > some problems in UFT-8 and UCS-2 conversion using libiconv and some
> > > ideas from Petr Mich&#65533;lek. I think the creator of mdbtools
>
> should
>
> > > validate this code to assure there is no problems.
> > >
> > > I will send those patches to the site
>
> http://sourceforge.net/tracker/?atid=302294&group_id=2294&func=browse .
>
> > > We have tested them with some MDB files in Japanese, Chinese,
> >
> > Russian,
> >
> > > Arabian, French and other languages. You can see columns/table
>
> names
>
> > and
> >
> > > data in those languages.
> > >
> > > Our next attempt will be to fix the bug #669739 - Shuffled columns
> >
> > from
> >
> > > Jet4. How could we send the modifications directly to the source?
>
> Is
>
> > > there any way to do it?
> > >
> > > Regards,
> > > Luciano
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - 50x more storage than other providers!
> > http://promotions.yahoo.com/new_mail
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by BEA Weblogic Workshop
> > FREE Java Enterprise J2EE developer tools!
> > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> > _______________________________________________
> > mdbtools-dev mailing list
> > mdb...@li...
> > https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
>
> --__--__--
>
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
>
>
> End of mdbtools-dev Digest

-- 
Jochen Riehm
DBRent GmbH
Joc...@db...

Re: [mdb-dev] UTF-8 support

[<br...@br...>]

I have it, but i need to tie up some loose ends.  I like the error
handling in this patch better the my simple pass/fail.  On the other
hand, there is no autoconf detection in the patch that I saw from my
quick perusal.  Also, my patch sets up iconv once per handle, this one
 seems to incur the overhead on each call (again from my quick look). 
Definately some good stuff in the patch though, and I'll try to merge
the two and we'll be better for it.

I'm still mulling over the problem of figuring out if the terminal
supports UTF8 or not.  I'm leaning toward turning it on if $LANG
contains the substring "utf8".  This works on RedHat 9/Fedora.  I'm 
very keen to hear what it is on other platforms.  Just,

echo $LANG

and post your results (along with the OS/distro you use of course) and
if we get enough responses we should be able to determine the correct
course of action.

669739 should be due to added/deleted/reordered columns and *should*
be fixed. It works for all the test cases I have anyway.  If your
willing to part with a database that still exhibits this behaviour,
I'll certainly have a looksee.

Brian

On Tue, 27 Jul 2004 17:02:04 -0700 (PDT), Jeff Smith wrote:

> 
> If I am not mistaken, Brian already has some code for this (not that
he
> would not be able to use any of your work), but has not checked it in
> due to some design decisions.  See message "Re: [mdb-dev] Old code"
> from
> July 17th.  I assume you are subscribed to the list.
> 
> As for bug 669739, do you have test case to confirm this bug (in the
> latest
> pre-release)?  A lot has changed in the code since the bug was
> reported and
> it may be a dead issue.
> 
>  -- Jeff S
> 
> 
> --- Luciano Miguel Wolf <luc...@fr...> wrote:
> > Hi mdbtools developers,
> > 
> > A few weeks ago I wrote to this list asking for UTF-8 support. In
the
> > mean time the company where I am working increased its interests in
> this
> > feature. I and co-worker (Alexandre Horst) have been working in
> source
> > code of libmdb and we have implemented the UTF-8 support. We have
> fixed
> > some problems in UFT-8 and UCS-2 conversion using libiconv and some
> > ideas from Petr Mich&#65533;lek. I think the creator of mdbtools
should
> > validate this code to assure there is no problems. 
> > 
> > I will send those patches to the site
> >
>
http://sourceforge.net/tracker/?atid=302294&group_id=2294&func=browse .
> > We have tested them with some MDB files in Japanese, Chinese,
> Russian,
> > Arabian, French and other languages. You can see columns/table
names
> and
> > data in those languages.
> > 
> > Our next attempt will be to fix the bug #669739 - Shuffled columns
> from
> > Jet4. How could we send the modifications directly to the source?
Is
> > there any way to do it?
> > 
> > Regards,
> > Luciano
> 
> 
> 		
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev

Re: [mdb-dev] UTF-8 support

[Luciano M. W. <luc...@fr...>]

Brian,

The answer is inline.

On Tue, 2004-07-27 at 21:56, br...@br... wrote:
> I have it, but i need to tie up some loose ends.  I like the error
> handling in this patch better the my simple pass/fail.  On the other
> hand, there is no autoconf detection in the patch that I saw from my
> quick perusal.  Also, my patch sets up iconv once per handle, this one
>  seems to incur the overhead on each call (again from my quick look). 
> Definately some good stuff in the patch though, and I'll try to merge
> the two and we'll be better for it.

That is good to hear. I am proud to see my changes in the source of
mdbtools.

> 
> I'm still mulling over the problem of figuring out if the terminal
> supports UTF8 or not.  I'm leaning toward turning it on if $LANG
> contains the substring "utf8".  This works on RedHat 9/Fedora.  I'm 
> very keen to hear what it is on other platforms.  Just,
> 
> echo $LANG
> and post your results (along with the OS/distro you use of course) and
> if we get enough responses we should be able to determine the correct
> course of action.

Mine is en_US.UTF-8 on Fedora-2.

Look on /usr/share/system-config-language/locale-list for Fedora-2 and
/usr/share/redhat-config-language/locale-list for RH9/Fedora-1.

> 
> 669739 should be due to added/deleted/reordered columns and *should*
> be fixed. It works for all the test cases I have anyway.  If your
> willing to part with a database that still exhibits this behaviour,
> I'll certainly have a looksee.
> 

I sent a mdb file a few moments ago to this list, with some explanations
of how to reproduce the error.

> Brian

Regards,
Luciano

Re: [mdb-dev] UTF-8 support

[Luciano M. W. <luc...@fr...>]

Jeff,

You are right about the email telling us that Brian was coding the UTF-8
support. There is no doubt that was a mistake to write a fix without
telling all developers. Even so, we had many samples of MDB files which
were not opening with the last mdbtools version (I mean from CVS). We
thought that was not difficult because there has been a patch for UTF-8
in mdbtools site. Our aim is helping on development and let be mdbtools
a better tool. We hope that our "slipped" don't come to misunderstand,
although we are not competing with the rest of developers.

By the way the bug 669739 is still active. There is a workaround there,
but for people which don't use Access, is not a good workaround. I
created a database with Access XP with one table. I inserted 2 lines of
data in this table. Then I created a second table with a copy of the
first one. Second I removed the first (Campo1) and the third (Campo3)
columns. Finally I insert a new row in second table. So open this
database with gmdb2 and the columns is shuffled and data of the last row
/ first column is missing. The file mdb is attached with this e-mail.

Regards,
Luciano


On Tue, 2004-07-27 at 21:02, Jeff Smith wrote:
> If I am not mistaken, Brian already has some code for this (not that he
> would not be able to use any of your work), but has not checked it in
> due to some design decisions.  See message "Re: [mdb-dev] Old code" from
> July 17th.  I assume you are subscribed to the list.
> 
> As for bug 669739, do you have test case to confirm this bug (in the latest
> pre-release)?  A lot has changed in the code since the bug was reported and
> it may be a dead issue.
> 
>  -- Jeff S
> 
> 
> --- Luciano Miguel Wolf <luc...@fr...> wrote:
> > Hi mdbtools developers,
> > 
> > A few weeks ago I wrote to this list asking for UTF-8 support. In the
> > mean time the company where I am working increased its interests in this
> > feature. I and co-worker (Alexandre Horst) have been working in source
> > code of libmdb and we have implemented the UTF-8 support. We have fixed
> > some problems in UFT-8 and UCS-2 conversion using libiconv and some
> > ideas from Petr Michlek. I think the creator of mdbtools should
> > validate this code to assure there is no problems. 
> > 
> > I will send those patches to the site
> > http://sourceforge.net/tracker/?atid=302294&group_id=2294&func=browse .
> > We have tested them with some MDB files in Japanese, Chinese, Russian,
> > Arabian, French and other languages. You can see columns/table names and
> > data in those languages.
> > 
> > Our next attempt will be to fix the bug #669739 - Shuffled columns from
> > Jet4. How could we send the modifications directly to the source? Is
> > there any way to do it?
> > 
> > Regards,
> > Luciano
> 
> 
> 		
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev
> 

Re: [mdb-dev] UTF-8 support

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

If I am not mistaken, Brian already has some code for this (not that he
would not be able to use any of your work), but has not checked it in
due to some design decisions.  See message "Re: [mdb-dev] Old code" from
July 17th.  I assume you are subscribed to the list.

As for bug 669739, do you have test case to confirm this bug (in the latest
pre-release)?  A lot has changed in the code since the bug was reported and
it may be a dead issue.

 -- Jeff S


--- Luciano Miguel Wolf <luc...@fr...> wrote:
> Hi mdbtools developers,
> 
> A few weeks ago I wrote to this list asking for UTF-8 support. In the
> mean time the company where I am working increased its interests in this
> feature. I and co-worker (Alexandre Horst) have been working in source
> code of libmdb and we have implemented the UTF-8 support. We have fixed
> some problems in UFT-8 and UCS-2 conversion using libiconv and some
> ideas from Petr Michálek. I think the creator of mdbtools should
> validate this code to assure there is no problems. 
> 
> I will send those patches to the site
> http://sourceforge.net/tracker/?atid=302294&group_id=2294&func=browse .
> We have tested them with some MDB files in Japanese, Chinese, Russian,
> Arabian, French and other languages. You can see columns/table names and
> data in those languages.
> 
> Our next attempt will be to fix the bug #669739 - Shuffled columns from
> Jet4. How could we send the modifications directly to the source? Is
> there any way to do it?
> 
> Regards,
> Luciano


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

[mdb-dev] UTF-8 support

[Luciano M. W. <luc...@fr...>]

Hi mdbtools developers,

A few weeks ago I wrote to this list asking for UTF-8 support. In the
mean time the company where I am working increased its interests in this
feature. I and co-worker (Alexandre Horst) have been working in source
code of libmdb and we have implemented the UTF-8 support. We have fixed
some problems in UFT-8 and UCS-2 conversion using libiconv and some
ideas from Petr Michálek. I think the creator of mdbtools should
validate this code to assure there is no problems. 

I will send those patches to the site
http://sourceforge.net/tracker/?atid=302294&group_id=2294&func=browse .
We have tested them with some MDB files in Japanese, Chinese, Russian,
Arabian, French and other languages. You can see columns/table names and
data in those languages.

Our next attempt will be to fix the bug #669739 - Shuffled columns from
Jet4. How could we send the modifications directly to the source? Is
there any way to do it?

Regards,
Luciano

[mdb-dev] support joins?

[Lee, K. H. <er...@in...>]

TODO list's Joins not yet done?

When you are going to support Joins? 0.6pre2 ??

I want to know that.

Thanks.
----
Lee, Kuk Hyun

[mdb-dev] library suffix problem

[Jonathan D. <dix...@ly...>]

My Makefile/C is a bit on the rusty side, so forgive me if this is a silly question.

When I configure and make the 0.6pre1 release on my machine (Fedora Core 2), the shared libraries wind up not getting the .so suffix I would expect.  While the standard programs link and run fine with this, I am having problems getting these libraries to work with other applications.

Where do I go to have the shared libraries get the .so suffix?

Thanks,

Jon Dixon
dix...@ly...
http://dixonjon.tripod.com/


-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

Re: [mdb-dev] Old code

[<br...@br...>]

It's ok to nuke.  I believe it's only Jet3 code anyway.  I haven't
revisited catalog.c in quite some time.

BTW, I've almost got iconv all ready to check in, however, I have a
bit of a philisophical question to pose to the list.  Right now, I am
converting all output to UTF-8 which works for later redhat/fedora 
installs and probably some other late-model distros.  Older
unices/distros use ISO8859 or similar 8bit character set.  What are
people's feelings on support for anything other than utf8 and how
should it be implemented (aka, $LANG -> iconv mapping? the strings as 
set are not compatible)?

Brian

On Sat, 17 Jul 2004 12:31:24 -0700 (PDT), Jeff Smith wrote:

> 
> In src/libmdb/catalog.c there is a big hunk of code in an 'if 0'
block
> which was replaced
> by a section commented as 'new method' in February 2002.  Is there
any
> reason to leave
> this old code here that would not be served just as well with the
> capabilities of CVS?
> Removing this block of code would cut the number of lines in this
file
> nearly in half.
> Just gimme the green light. :-)
> 
>  -- Jeff Smith
> 
> 
> 		
> __________________________________
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
> http://advision.webevents.yahoo.com/yahoo/votelifeengine/
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev

[mdb-dev] Old code

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

In src/libmdb/catalog.c there is a big hunk of code in an 'if 0' block which was replaced
by a section commented as 'new method' in February 2002.  Is there any reason to leave
this old code here that would not be served just as well with the capabilities of CVS?
Removing this block of code would cut the number of lines in this file nearly in half.
Just gimme the green light. :-)

 -- Jeff Smith


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

[mdb-dev] MDB Tools Executable Generation

[t d <td...@ya...>]

Dear Sirs,
 
Thank you for your source code on MDB Tools. I've just downloaded the 
file named mdbtools-0.5.tar.gz from your Website. Having looked into the 
source code, I can't see where to deciphering the MDB version 200x 
password. A a man, interested in helping development, and due to the 
shortage of present time to carefully read into each files/line of code, I 
firstly want to quickly compile the source to generate .EXE file under 
Windows OS using Microsoft Visual C++ 6.0.
 
In order to saving time, please tell me the way to do it, and I'm 
pleased to work with you for further project development.
 
I look forward to hearing from you soon.
 
Best regards,
 
Your co-worker
Dung


		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.

[mdb-dev] Release of 0.6

[Art D. <ar...@mu...>]

I hate to ask a question that's probably been asked before, but I looked 
back a bit in the archives and didn't see it, so.

When is version 0.6 expected to be released? Not rushing anyone, just 
trying to get a general idea to see if we'll be able to use it.

Thanks in advance.

-- Art

[mdb-dev] java - sql parser now parses common sql

[Calvin S. <cal...@ho...>]

the java sql parser is now good enough to parse common sql, if your using it 
and find a sql it can't parse let me know.  Of course the engine can't 
execute much,  I'm now off to re-write the engine to support all the sql the 
parser does.

Calvin

_________________________________________________________________
MSN Life Events gives you the tips and tools to handle the turning points in 
your life. http://lifeevents.msn.com

[mdb-dev] Can MDBTools covert old MSAccess's databases?

[<las...@sa...>]

Can it convert MSAccess 6.x or something databases?
Can it? If it can, I'm very happy!

Thanks,
Lasse Liehu

Re: [mdb-dev] dash in table name

[<br...@br...>]

In src/sql/lexer.l look for the IDENT token.  Change:

\"[A-z][A-z0-9 _#@]*\"   {

to 

\"[A-z][A-z0-9 _#@-]*\"   {

This will cover the "table-name" case (that is, when using quotes).  I
don't think we want to do this in the bare (non-quoted) case (the NAME
token) since a construct like:

select column1-column2 from table 

should be allowable and unambigous.  Does anyone have a reference to
the allowable table/column identifiers?  It'd be nice to not have
these issues keep cropping up.

Brian
  

On Wed, 30 Jun 2004 10:41:25 -0500, "Jonathan Dixon" wrote:

> 
> I have been working at trying to use the SQL command line to perform
> select commands on a database that includes hyphens in some of the
> table names. For example:
> SELECT * FROM Members-Personal
> I have tried enclosing the table name in [], (), "", '', and any
> others I could come up with as well as escaping the hyphen with a
> backslash.  All of them simply cause a syntax error in the SQL
> command. Leaving out any quotation (such as shown above) results in
an
> error that Members is not a valid table name in this database. 
> Unfortunately I do not have the flexibility in this case to simply
> rename the tables.
> 
> I have downloaded the 0.6pre1 files from the server and the problem
> persists.  I can provide a small sample MDB file if others wish to
> verify this behavior.  If this is a known problem I am willing to
help
> correct it if someone can point me to the proper location where this
> parsing occurs.
> 
> Thanks,
> 
> Jon Dixon
> dix...@ly...
> http://dixonjon.tripod.com/
> 
> 
> -- 
> _______________________________________________
> Find what you are looking for with the Lycos Yellow Pages
>
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> https://lists.sourceforge.net/lists/listinfo/mdbtools-dev

[mdb-dev] dash in table name

[Jonathan D. <dix...@ly...>]

I have been working at trying to use the SQL command line to perform select commands on a database that includes hyphens in some of the table names. For example:
SELECT * FROM Members-Personal
I have tried enclosing the table name in [], (), "", '', and any others I could come up with as well as escaping the hyphen with a backslash.  All of them simply cause a syntax error in the SQL command. Leaving out any quotation (such as shown above) results in an error that Members is not a valid table name in this database.  Unfortunately I do not have the flexibility in this case to simply rename the tables.

I have downloaded the 0.6pre1 files from the server and the problem persists.  I can provide a small sample MDB file if others wish to verify this behavior.  If this is a known problem I am willing to help correct it if someone can point me to the proper location where this parsing occurs.

Thanks,

Jon Dixon
dix...@ly...
http://dixonjon.tripod.com/


-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10