bizzare names for auto-discovered db relationships

Hi,

All was going relatively well with Servoy 2.1.1 on Linux with Java 1.5 and the DB in mysql (using mysql-connector-java-3.0.15-ga-bin.jar) till I invoked creation of database defined relations, to refresh the list due to some db changes.

Now I find locked relationships named like “0_4191”. If I try to edit one of these it looks reasonable in the dialogue box save that the “Relationship name” is blank.

Any ideas what’s up here?

Thanks,
Neale.

i just tested it on mysql 4.1.7 with driver mysql-connector-java-3.0.15-ga-bin.jar. It generates tablename_ibfk_3 kind of relations that i can open (and i see the name disabled in the name field) and i can press OK. Without any errors.

Do you have an example create script that i can insert into a mysql db with some relations you are using?

I’m not sure what you mean by “tablename_ibfk_3 kind of relations” - I’m accustomed to seeing auto-discovered relations named like “db_foo_to_bar” (where foo and bar are table names). At the moment new ones are showing i the index like “0_4577” and in their edit dialogue with no name - quiet “odd”. FWIW, I’m using mysql “4.0.13-log” - it used to work just fine.

I just reporduced this by creating a fresh database with the appended script, creating a db server pointing to it, creating a new solution (just one table) then invoking “Create” of “database Defined Relations”. The three discovered relations appear in trhe index as 0_4577, 0_4574 and 0_4575. See attached screen shot.

Any ideas?

Thanks,
Neale.

-- Created by dia2sql.pl v1.2-5ntb1 (Fri Apr 23 11:18:55 EST 2004)

-- 
-- Table structure for table 'post_print_states'
-- 

CREATE TABLE post_print_states (
        pp_states_id INTEGER AUTO_INCREMENT NOT NULL,
        pp_state_code CHAR(3) NOT NULL,
        pp_state_desc VARCHAR(50),
        PRIMARY KEY(pp_states_id),
        INDEX pp_state_code_idx (pp_state_code)
) TYPE=INNODB;


-- 
-- Table structure for table 'post_print_types'
-- 

CREATE TABLE post_print_types (
        pp_type_id INTEGER AUTO_INCREMENT NOT NULL,
        pp_type_code CHAR(1) NOT NULL,
        pp_type_desc VARCHAR(50),
        PRIMARY KEY(pp_type_id),
        INDEX pp_type_code_idx (pp_type_code)
) TYPE=INNODB;


-- 
-- Table structure for table 'post_apdata'
-- 

CREATE TABLE post_apdata (
        post_apd_id INTEGER AUTO_INCREMENT NOT NULL,
        post_apd_pcode NUMERIC(4),
        post_apd_locality VARCHAR(40),
        post_apd_state CHAR(3),
        post_apd_comments VARCHAR(40),
        post_apd_deliveryoffice VARCHAR(40),
        post_apd_psi NUMERIC(3),
        post_apd_parcelzone CHAR(2),
        post_apd_bspnum NUMERIC(3),
        post_apd_bspname VARCHAR(40),
        post_apd_category VARCHAR(40),
        PRIMARY KEY(post_apd_id),
        INDEX post_apd_pcode_idx (post_apd_pcode),
        INDEX post_apd_locality_idx (post_apd_locality),
        INDEX post_apd_state_idx (post_apd_state),
        INDEX post_apd_psi_idx (post_apd_psi),
        INDEX post_apd_bspnum_idx (post_apd_bspnum)
) TYPE=INNODB;


-- 
-- Table structure for table 'post_print_plan'
-- 

CREATE TABLE post_print_plan (
        pp_plan_id INTEGER AUTO_INCREMENT NOT NULL,
        pp_plan_state CHAR(3) NOT NULL,
        pp_plan_psi NUMERIC(3) NOT NULL,
        pp_plan_type_code CHAR(1) NOT NULL,
        pp_plan_desc VARCHAR(50),
        PRIMARY KEY(pp_plan_id),
        INDEX pp_plan_state_idx (pp_plan_state),
        INDEX pp_plan_psi_idx (pp_plan_psi),
        INDEX pp_plan_type_code_idx (pp_plan_type_code),
        FOREIGN KEY (pp_plan_state) REFERENCES post_print_states (pp_state_code),
        FOREIGN KEY (pp_plan_type_code) REFERENCES post_print_types (pp_type_code)
) TYPE=INNODB;


-- 
-- Table structure for table 'post_print_presort'
-- 

CREATE TABLE post_print_presort (
        pp_presort_id INTEGER AUTO_INCREMENT NOT NULL,
        pp_presort_psi NUMERIC(3) NOT NULL,
        pp_presort_pcode NUMERIC(4) NOT NULL,
        PRIMARY KEY(pp_presort_id),
        INDEX pp_presort_psi_idx (pp_presort_psi),
        INDEX pp_presort_pcode_idx (pp_presort_pcode),
        FOREIGN KEY (pp_presort_psi) REFERENCES post_print_plan (pp_plan_psi)
) TYPE=INNODB;

just tested youre script on my mysql db.
And i do get other names and that name is also showed in the relations dialog.

i get “tablename_ibfk_1” for example the table “post_print_plan” generates one relation “post_print_presort_ibfk_1”

so i really can’t reproduce the things you get. It has something to do with youre mysql or driver version

Do you have mysql.jar also in youre driver lib?

jcompagner:
just tested youre script on my mysql db.
And i do get other names and that name is also showed in the relations dialog.

i get “tablename_ibfk_1” for example the table “post_print_plan” generates one relation “post_print_presort_ibfk_1”

Hmmm… FWIW that’s a different naming style from what I was seeing (db_foo_to_bar).

jcompagner:
so i really can’t reproduce the things you get. It has something to do with youre mysql or driver version

Shouldn’t be the driver, we’re both using “mysql-connector-java-3.0.15-ga-bin.jar”? I haven’t changed the mysql version in a long time, since before this was working. More recent changes are Servoy and Java (currently: “Servoy R2 2.1.1 build-313 on Linux using Java 1.5.0”)

jcompagner:
Do you have mysql.jar also in youre driver lib?

Sort of, it’s there but renamed:

$ cd /usr/local/servoy/drivers/
$ ls
firebird.zip  mysql-connector-java-3.0.15-ga-bin.jar  pg74.1jdbc3.jar
jconnect.zip  mysql.jar--                             postgresql.jar--

Where does all that leave us?

Thanks,
Neale.

yes! remove the mysql.jar!
That is an old one.

OK, tried that. Unfortunately it didn’t help :-(

FWIW, I also tried reverting to Java 1.4 yesterday - that didn’t help either.

I just tried mysql-connector-java-3.0.16-ga-bin.jar - same problem :-(

Any more ideas?

Thanks,
Neale.

if you removed the mysql.jar from the driver folder and only have the xx-16 in it. Then i can only think of 2 things the version of mysql ( i use 4.1.7) or as second the use of linux as combo with mysql version.

But the latter shouldn’t really matter.

If you make a new database and a new connection to it in servoy and you use that sample script you gave me. Are you still getting those strange names?

jcompagner:
if you removed the mysql.jar from the driver folder and only have the xx-16 in it. Then i can only think of 2 things the version of mysql ( i use 4.1.7) or as second the use of linux as combo with mysql version.

But the latter shouldn’t really matter.

Yes, and this version of mysql used to be just fine with this function.

jcompagner:
If you make a new database and a new connection to it in servoy and you use that sample script you gave me. Are you still getting those strange names?

Just did that, and got the same result (but different numeric values) :-(

Hmmm… a possibly relevant data point: the discovered relation name (e.g. “0_4582”) in the parent table matches the mysql constraint name in the child table (as shown by “SHOW CREATE TABLE ”. Previously this would have been “db_parent_to_child”

Thanks,
Neale.

One more thing: after quitting Servoy I noticed this in the terminal window: “Destroy error java.lang.NullPointerException”. No idea if it’s related.

Neale.

Update: probably not related - subsequents showed that this message appears when I quit servoy (i.e. long after the relation discovery process). Neale.

the error doesn’t seem to be related.

But then i am out of idea’s. I can’t reproduce it, it works just fine in my setup.

I am having the same problem. I just made a new database and solution using the following code:

CREATE TABLE Parent (
  parent_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  PRIMARY KEY(parent_id)
)
TYPE=InnoDB;

CREATE TABLE child (
  child_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  parent_id INTEGER UNSIGNED NOT NULL,
  PRIMARY KEY(child_id),
  INDEX child_FKIndex1(parent_id),
  FOREIGN KEY parent_to_child(parent_id)
    REFERENCES Parent(parent_id)
      ON DELETE NO ACTION
      ON UPDATE NO ACTION
)
TYPE=InnoDB;

Servoy disvovered the following two relations:

under child, ‘parent’: parent_id = parent_id;
under parent, ‘0_236’: parent_id = parent_id;

Previously, the relation under parent would have been named ‘db_parent_to_child’, and the relation under child would not have been found at all. It is nice that it is finding both relations now, but the naming of them is very odd.

with those tables i get under child “parent” and under parent “child_ibfk_1”
and that child_ibfk_1 name is also the name i see with Mysql Administrator.