fenway

You where clause will currently return pretty much all combinations of start/end... so why include it? For the "true" range, use BETWEEN.

With no test data, not test output and no query... we're not going to get anyhere.

IMHO, that's not even remotely required.

Same place as before, go to the table screen by clicking on the table... you may want to look though some phpmyadmin tutorials.

You need "IF EXISTS".

Maybe when you're testing, but never in production... Actually, that's most useful for assignment of @_.

You will have to rethink it... you aren't supposed to have a set number of fields, you're supposed to have another table that links players to teams to weeks.

I'm not sure if you really mean "deleted"... maybe keep a count?

I've never heard of such a thing... what query?

Glad you got it working... after all, that's why we're all here.

When you're getting back all of the records, don't add that to the where clause, it's not limiting your resultset.

There are plenty of terrible ideas on this forum, and I'll continue to point them out... like storing "lists" in the single field, trying to change the auto_increment value, etc. Besides, terrible doesn't always mean bad per se... just extremely distressing. And more than that, I haven't seen any attempt to implement the plethora of solutions provided in the link I gave you.

LIKE doesn't use an index, so it's expensive. And I was talking about the parents in the joins.

Storing dates as anything but dates -- that's not my opinion, that's plain data corruption. Since obviously you don't feel like doing any research of your own, try this refman page.

Wow, that's a terrible solution. Leave it as a day, convert it the current year, and then use between...

You could also make a copy of this table and normalize it for the purposes of what you're trying to accomplish.

Why is there a veh_group? The xfer table should link event_id to veh_id, nothing more.

Did you read that discussion? It's rather in-depth, and has many solution.

You can use FIND_IN_SET multiple times... or a SUBSTRING search with commas... it will be horribly slow.

Birthdays are funny things... the mysql refman page on date/time functions actually has a rather lengthy discussion on this. Ultimately, you simply need to "swap out" the year with the current year.

Maybe I've totally lost you... what is it that you want to calculate?

last_insert_id(columnname) is thread-safe.

How does everyone fall into this trap? Get the "writer of the db" to normalize the database.

That's a lot more work for the server for no reason... and if you don't have matching records for table4, that order by is going to be useless... also, why the strange parentheses?

Why would you store a list in a single field... it's not a problem with the IN command, it's a problem with your table design. Normalize it, and you'll be fine.