If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

In my case, "x"=15. In "projdb", i have `userdata`.`userid` as a foreign key referencing `users`.`id` Both userid and id are INT, and `id` is the primary key wi auto increment in `users`. I have set ON UPDATE CASCADE, and ON DELETE CASCADE.

This would indicate that you did not set up your PRIMARY KEY as an AUTO_INCREMENT FIELD.
You're not specifying a value to use as the PK, so MySQL is using the default value ( 0 ).

Obviously, this will only work once.

------------
As for your foreign keys design:

...Is there a reason you're associating *entire tables* to individual users? Is the table just for them? If (as I suspect) not, then you should be associating the record(s) to the user, not the table itself.

This next part might not be relevant depending on your data structure, but most likely applies.

A relations table (e.g., your userdata table) is good for many-to-many relationships. A network of friends is a good example of this type of relationship.

However, where a relationship is many-to-one (the record is one of possibly several that are associated only with one user), it often makes more sense to store the foreign key with the "many" record itself. An example:

Viola!, associating "many" records (emails) to their "one" records (user) is done, quick and simple.
Storing these relationships in a separate table would only complicate querying and slow down performance overall.

We have to store each users's information on a separate table, this is my given problem specification. As I've seen, the next laboratory tackles records. I'm guessing I'll have to implement this same thing with records.

Nevertheless, thank you for your time and for your given explanation. I never would have thought that was the problem.

We have to store each users's information on a separate table, this is my given problem specification. As I've seen, the next laboratory tackles records. I'm guessing I'll have to implement this same thing with records.

That still sounds "wrong" - unless each user has completely different types of info (seems unlikely), then it should all be in the same table. Storing similar info about different users in different tables is, quite simply, absurd. But perhaps there's something else here that I don't understand yet.