SQL Power Software Forum

Actually, the engine only tried deleting the duplicate in the last table (which is the master table). The problem was that the child record that was referencing it was not deleted, so trying to delete the master record resulted in a foreign key constraint violation.

We've run into another issue with the Merge Engine. If I have 'DEL_DUPLICATE_IND' set to 'N' in the merge criteria, the Merge engine still attempts to delete the duplicate anyway. This is causing the Merge engine to fail because we have a child record with a foreign key referring to the duplicate, resulting in a constraint violation.

As far as we can tell, our merge rules are set properly. We used Wireshark to check the SQL statements being sent from the Merge Engine, and it's definitely trying to delete the duplicate record. We also made sure that our merge rules are definitely set to not delete duplicates.

Hey Prodoc,

Thanks for the tip. We'll look into it.

Unfortunately, we find the current implementation of the Index editor confusing and unintuitive, so we can hopefully fix that along with this problem if the manual index creation is indeed the cause.

Okay, we think the scenario we were testing on probably had the update to the table causing duplicate primary keys. We will try this on a different scenario

We've been testing the Merge engine, the default behaviour appears to be that it will delete child records that were point to the duplicate records in the parent source table if you are deleting the parent table duplicates.

However, what if you wish to keep those child records, and simply point them to the master parent record? How would I set up my merge rules to achieve this?

We didn't really do anything fancy for our test case. The source table we created was rather simple:

But with the following change, the engine was able to create its table with no problems:

There was, because it was creating a table with columns using the DOUBLE data type, but we figured out how to work around that.

Okay, we figured it out. Basically, the source table's primary key was a NUMBER with no specified precision. So, the engine ended up making a result table using DOUBLE. In the other case, the source table primary key had a set precision of 22, so the engine set the result table type to DECIMAL.

We found out that the Match engine is trying to create a copy of the result table, but with a data type that Oracle doesn't support.

The actual key in the table we're matching on is a NUMBER type, but this statement is creating the table with DOUBLE types, which Oracle doesn't have. The strange thing is, in another test, it created a similar table, but with DECIMAL types, and that worked fine.

I've been testing the new MatchMaker GUI with the existing C engine, and I'm running into some problems using the engine on a simple table.

MATCHMAKER_TEST
-------------------------
TESTNUM TESTSTRING
1 foo
2 foo
3 bar
4 bar

I've set up a simple Match criteria on the column TESTSTRING.

I've attached my log output. I've noticed that it's running SQL queries for tables that have the names of my source table and my result table except they have two zeroes (00) appended to them. (ex. MATCHMAKER_TEST00 and MATCHMAKER_TEST_RESULT00). However, these tables do not exist in the database, and it seems to be causing the engine to fail. Is the engine supposed to create these tables itself?

Hi park,

Thanks for reporting this issue.

I've filed a bug report in our Bugzilla database.

http://trillian.sqlpower.ca/bugzilla/show_bug.cgi?id=1352

If we have any trouble reproducing the issue, we may have to ask you for more details later.

Hi again,

I looked into fixing the reverse engineering problem, and it was a pretty simple fix, so it should be available in the upcoming nightly build.

http://nightlybuild.sqlpower.ca/architect/0.9.8-20070822/

Note that this link won't be available until after August 22, 1:00 AM EST.

Hi Peter,

Sorry for the delayed reply.

Thanks for pointing this out. I've looked into this and it does appear to be a real bug. I've posted a bug report into out Bugzilla database.

http://trillian.sqlpower.ca/bugzilla/show_bug.cgi?id=1351

I'll post another reply when we've got a fix checked in.

Hi aeg,

Unfortunately, we have not been able to reproduce this issue on our own Windows XP machines, so we'll need some more information.

Are you able to consistently reproduce this issue?

Does the application show any additional information along with the NullPointerException? (like a stack trace for example?)

Does the NullPointerException occur when running Power*Architect or running the installer?

If you can also provide step-by-step detail on what you're doing as you reproduce the problem, that would also be helpful.

You can also see if you still get the problem when installing the latest nightly build.
http://nightlybuild.sqlpower.ca/architect/0.9.8-20070816/

Hi Peter,

The nightly build has been fixed, so you should be able to re-download the nightly build and run it.

http://nightlybuild.sqlpower.ca/architect/0.9.8-20070815/