> Hello, I've heard that Hypersonic SQL doesn't support foreign keys? This
> is a bit confusing. I'm pretty much an SQL newbie and am having a bit of
> a problem, though I suspect it's more to do with my rubbish SQL than
> hypersonic.
I can't tell you about Hypersonic's foreign key support, but your SQL is a problem.
> I am trying to create two tables.
>
[quoted text clipped - 19 lines]
> update the status table with the status, connectiontime and username, it
> just gets duplicated.
I don't know what you are expecting when you talk about the username column in the
status table being updated from the users table. An ON UPDATE clause in the foreign key
declaration would update status when the referenced username in users is changed, but
otherwise there is no automatic update. You have to maintain both tables with separate
operations.
> For example, after creating the tables, inserting two users in the users
> table and then updating one user in the status table I get this:
You mean inserting one row in the status table.
> select * from users,status
>
> Username Ipaddress status connectiontime username
>
> name2 111222333444 Away 546564564 name2
> name3 555666777888 Away 546564564 name2
You have to join the two tables. Try:
SELECT * FROM users LEFT OUTER JOIN status ON users.username = status.username
That will show an understandable result ... name3 doesn't have a referencing status row.

Signature
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
Jeffrey Spoon - 20 Mar 2005 01:48 GMT
>I can't tell you about Hypersonic's foreign key support, but your SQL
>is a problem.
That doesn't surprise me ;)
>I don't know what you are expecting when you talk about the username
>column in the
[quoted text clipped - 5 lines]
>tables with separate
>operations.
Ok, that's fine. I don't know what I'm doing, as you have realised. I
thought the username would magically appear in the status table as it
was a foreign key.
>> For example, after creating the tables, inserting two users in the users
>> table and then updating one user in the status table I get this:
>
>You mean inserting one row in the status table.
Yep, now that you explained.
>> select * from users,status
>>
[quoted text clipped - 10 lines]
>That will show an understandable result ... name3 doesn't have a
>referencing status row.
Ah, I see. This should help me a lot. Thanks very much Lee.

Signature
Jeffrey Spoon
Lee Fesperman - 20 Mar 2005 02:43 GMT
> >I can't tell you about Hypersonic's foreign key support, but your SQL
> >is a problem.
>
> That doesn't surprise me ;)
You might try the SQL Tutorial at http://www.firstsql.com/tutor.htm (I wrote it.)

Signature
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
Jeffrey Spoon - 20 Mar 2005 17:51 GMT
>> >I can't tell you about Hypersonic's foreign key support, but your SQL
>> >is a problem.
[quoted text clipped - 3 lines]
>You might try the SQL Tutorial at http://www.firstsql.com/tutor.htm (I
>wrote it.)
Excellent thanks. I've actually got it sort-of working due to your
tutorial. I still managed to get duplicate usernames somehow, but I
think I can figure out what it is.
Cheers

Signature
Jeffrey Spoon
Lee Fesperman - 20 Mar 2005 22:27 GMT
> >You might try the SQL Tutorial at http://www.firstsql.com/tutor.htm (I
> >wrote it.)
>
> Excellent thanks. I've actually got it sort-of working due to your
> tutorial. I still managed to get duplicate usernames somehow, but I
> think I can figure out what it is.
Glad it helped. I'm not sure what you mean by duplicate usernames, though duplicate fk
references are natural unless you constrain them.
Come back if you are still having problems.

Signature
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
Jeffrey Spoon - 20 Mar 2005 22:55 GMT
>> >You might try the SQL Tutorial at http://www.firstsql.com/tutor.htm (I
>> >wrote it.)
[quoted text clipped - 8 lines]
>
>Come back if you are still having problems.
Well, they're not really duplicate usernames, just the foreign keys. If
that's normal that's ok. Cheers

Signature
Jeffrey Spoon
Lee Fesperman - 21 Mar 2005 01:50 GMT
> > ... I'm not sure what you mean by duplicate usernames,
> > though duplicate fk references are natural unless you constrain them.
>
> Well, they're not really duplicate usernames, just the foreign keys. If
> that's normal that's ok. Cheers
I should have noticed your primary key for the status table. It indicates there can be
more than one entry per user. Kudos for using primary and foreign keys.

Signature
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
Jeffrey Spoon - 21 Mar 2005 15:46 GMT
>> > ... I'm not sure what you mean by duplicate usernames,
>> > though duplicate fk references are natural unless you constrain them.
[quoted text clipped - 5 lines]
>indicates there can be
>more than one entry per user.
Oops, that's not supposed to happen.

Signature
Jeffrey Spoon
Lee Fesperman - 22 Mar 2005 02:45 GMT
> >> > ... I'm not sure what you mean by duplicate usernames,
> >> > though duplicate fk references are natural unless you constrain them.
[quoted text clipped - 7 lines]
>
> Oops, that's not supposed to happen.
IOW, there can be only one status row for each user (and some users may not have an
associated status row)? Then you should make the username column the (sole) Primary Key
of the status table, so the column is both the Primary Key and a Foreign Key referencing
the users table.
This is a 1:1 relationship between status and users. It is used when some users might
not have a status entry, but when they do there is only one. Again, that is perfectly
natural if that is what your design calls for.
Be sure and read the above very carefully to make sure it reflects what you want. I'm
afraid the SQL Tutorial doesn't cover these kinds of design issues; it only covers the
SQL language and the structure of tables and keys.

Signature
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
Jeffrey Spoon - 22 Mar 2005 20:37 GMT
>Be sure and read the above very carefully to make sure it reflects what
>you want. I'm
>afraid the SQL Tutorial doesn't cover these kinds of design issues; it
>only covers the
>SQL language and the structure of tables and keys.
No you've got it exactly. The reason I didn't put username as the
primary key in the status table is because I wasn't sure if you could
have it as a foreign and primary key at the same time. That should work
how I originally intended.
Thanks again.

Signature
Jeffrey Spoon