[shawn_h]

peterlaursen wrote on Oct 3 2005, 11:03 AM:

i quote from that link:

That makes sense! 

But you are sure that you did not specify some DEFAULT-value from the Migration Tool GUI yourself?  I still doubt that an empty statement in the XML generally is a problem.  But a 0 is with an autoincremented field.

[post=”7408″]<{POST_SNAPBACK}>[/post]

I am positive I didn't specify any default values at all. it generated the default values all by itself and the y were all like this: NULL. This should not be there if dba deosn't want it to be included.

Here's a copy of my job file! The empty lines you see in there further down the file is because I had to remove all the default statements. Of course, I put them back in there in the begining of the file for you guys to see what I had to remove.

But it's really simple: with the default statements set to NULL, my jobs are failing and without them, they'll run. They shouldn't be there to begin with and if they're there it should be because the dba decided to include them in.

Does this make sense? 🙂

[shawn_h]

peterlaursen wrote on Oct 1 2005, 09:33 PM:

I also googled a little and found this:

http://techrepublic.com.com/5100-10878_11-5148530.html

ISAM = Indexed Sequential Access Method.

It sounds like the DATAFLEX/POWERFLEX systems that I worked a lot with 15 years ago!

But probably not very relevant!  After all data are transferred by the ODBC-driver.The key point is what SQL is generated by the SJA when interpreting the XML.  And it is the “create table …” that fails for some reason.

[post=”7389″]<{POST_SNAPBACK}>[/post]

I do not believe that is related to what I am talking about; however, for your benefit, I did find the link that prompted me to remove NULL entries in my job files and here is it:

http://www.karakas-online.de/forum/viewtopic.php?t=2732

i'll send a copy of one of my job files shortly.

[shawn_h]

peterlaursen wrote on Sep 30 2005, 09:56 PM:

I am afraid you must explain a little bit more!

I just tested with MySQL 5.0.13 (on windows) and SQLyog 4.2 beta 2 and import from MS-Access.  The empty defaults like in the XML does not prevent correct functioning here.

However undoubtedly you came across som information that solved your problem.

Could you point to those resources more precisely? 

Is it a 5.0.13 only problem, a Mac OS-X only problem or what ?

Does it take a specific server configuration to reproduce?

What is your ODBC-source ?

Also a small XML-file that does not work with on your system and does work without them would be useful.

You will need to give information so that problem can be reproduced!  Also why not link to the resources that you googled?  We don't read thought.   Though it sometimes would be practical!   😉

[post=”7384″]<{POST_SNAPBACK}>[/post]

Ok, I try to answer most of your questions (as I am not working over the weekend) that you have asked above:

The error I was getting is a 1067 error. When googled, I came across a post that said DEFAULTS should be removed when creating new tables in Mysql 5.x. So, this gave me a clue as I was also creating tables from my ODBC source. So, after I removed all the default statements from xml job files, it started to create the tables and ran smoothly.

Before, I did this, I tested against 4.x without any problem. So, I firmly believe it's a 5.x problem .

My ODBC source connects to an ISAM database through some proprietary drivers on windows platform. These same drivers have been working without a problem with version 4.x.

As far as I know, it doesn't take any specific server configuration to reproduce the error. Having said that, I only tested on my compiled version of the new MySQL server on Mac osx so I cannot for sure say that it can be reproduced on Linux and/or windoze; however, seemingly it appears it's a client server type of problem; not related to underlying os. Before, I googled, I tried changing the storage engine without any success.

I'll send you a sample of my xml file Monday when I go back to work.

You mean you don't have a sixth sense and cannot read my mind across the ocean, that's too bad,ey! 😉

[shawn_h]

peterlaursen wrote on Sep 22 2005, 05:01 PM:

Dublicated rows simply can't exist if there is a PK.  The server prevents this! At least the value of the PK differs for each row!

Please explain!

Right on! that's exactly why you'd want to see a list of duplicated rows; to determine what to do with them, if anything. Maybe, the admin decides to change something and update the target.

Does this make sense?

[shawn_h]

Ritesh wrote on Sep 22 2005, 11:53 PM:

Can you provide an example to explain the issue a little more?

[post=”7285″]<{POST_SNAPBACK}>[/post]

Sure can! If two databases are being synced up and in the first db in one table there is a field that is a PK but the same field in the second table is not a PK, then, the software should allow for the update in a one way situation to the second database's table.

[shawn_h]

I see!

So if we're talking about say 10 tables, then we're talking about 10 import jobs and 10 notification jobs, executed serially, one after the other. Is that right?

Do you have an example I can use?

[Author]

Posts