You're welcome.
Well, MySQL (v.3.23, I believe) supports subqueries like the one I wrote above, so you should be able to get the query to work. And doesn't really matter what scripting language you use, all you have to do is use SQL that works with whatever database storage app you are using.
And you really have to get away from the flat file model, and think more "relationally" between objects in your dataset.
BTW: For future development of your system and if at some point you want to allow your web users to have multiple players, the better thing to do is create an intersection table (to allow multiple players to be associated with multiple users), like the following:
tbl_User_Players
UserID (UNIQUE, INDEX)
PlayerID (UNIQUE, INDEX)
You can still use codes to restrict the number of players like the following:
SELECT tbl_Players.Player_First_Name, tbl_Players.Player_Last_Name, tbl_Players.PlayerID
FROM tbl_Players
WHERE tbl_Players.PlayerID NOT IN (SELECT PlayerID FROM tbl_User_Players)
Using M<->M connections with intersection tables will allow more flexibility for future growth and development of your system. Rather than having to switch from 1<->1 and edit your USERS table constantly to fit the new schema that you apply later on. Of course, the more intersection tables you add, the more JOINS you have to apply, which takes more time to process in terms of CPU cycles and Memory, but the time you save in configuring your system in a flexible manner outweighs the extra ms (milliseconds) of data processing, IMO.
========================================
Buh Bye!
Cheers,
Me
Well, MySQL (v.3.23, I believe) supports subqueries like the one I wrote above, so you should be able to get the query to work. And doesn't really matter what scripting language you use, all you have to do is use SQL that works with whatever database storage app you are using.
And you really have to get away from the flat file model, and think more "relationally" between objects in your dataset.
BTW: For future development of your system and if at some point you want to allow your web users to have multiple players, the better thing to do is create an intersection table (to allow multiple players to be associated with multiple users), like the following:
tbl_User_Players
UserID (UNIQUE, INDEX)
PlayerID (UNIQUE, INDEX)
You can still use codes to restrict the number of players like the following:
Quote:
SELECT tbl_Players.Player_First_Name, tbl_Players.Player_Last_Name, tbl_Players.PlayerID
FROM tbl_Players
WHERE tbl_Players.PlayerID NOT IN (SELECT PlayerID FROM tbl_User_Players)
Using M<->M connections with intersection tables will allow more flexibility for future growth and development of your system. Rather than having to switch from 1<->1 and edit your USERS table constantly to fit the new schema that you apply later on. Of course, the more intersection tables you add, the more JOINS you have to apply, which takes more time to process in terms of CPU cycles and Memory, but the time you save in configuring your system in a flexible manner outweighs the extra ms (milliseconds) of data processing, IMO.
========================================
Buh Bye!
Cheers,
Me