Subject: Re: Teams doesn't work yet - fixed, and the SQL I sent you was incomplete
Evan,
First, an apology. The CREATE TABLE statement I emailed you was incomplete. It
had the right column names but was missing nine columns that the save path
needs. That caused both of the things you saw:
The Teams save kept returning HTTP 400, because saving a team writes to columns
that table didn't have.
Your personnel, equipment and vehicles disappeared, because several screens
filter on a column that was missing, so those queries failed and the pages came
back empty. Your data was never gone - and you found the right fix on your own
by re-running the migrations with --force, which is exactly what I would have
told you to do.
You should not have had to debug my SQL. That is now fixed in the product
rather than in an email: the upgrade checks for every column the Teams screen
needs and adds whatever is missing. I reproduced your exact error on a copy of
your table shape, confirmed it fails the same way you saw, then ran the fix and
confirmed a team saves correctly and existing teams survive untouched.
TO GET THE FIX
v4.1.0 is out. If you cloned the repository with git:
Step 1 - git pull
Step 2 - php sql/run_migrations.php
That's it. The migration is safe to run more than once and does not delete
anything.
If you downloaded a zip file instead of cloning, it is worth ten minutes to
switch over to git. After that, staying current is just "git pull" - you get
fixes the day they land instead of waiting for me to bundle a release, which
matters when you are the one who found the bug. There are two short
walkthroughs:
When you have updated, could you confirm the Teams screen loads and that
creating a team saves? That is the one thing I would like verified by someone
other than me.
ON RESTARTING
You asked about restarting - turning the XAMPP servers off and back on from the
XAMPP Control Panel is exactly right, that is the normal way on XAMPP. Two
small refinements:
Use Stop and wait until the panel actually shows MySQL as stopped before you
start it again. Closing the window or ending the process is what leaves tables
damaged.
After a power loss or a battery shutdown, MySQL may take a minute or two on the
next start while it repairs itself. Let it finish. That pause is the thing that
originally made your install look like a fresh one.
SOMETHING THAT CAME OUT OF YOUR PROBLEM
Your laptop losing power is the reason v4.1.0 has automatic backups. They are
on by default now, so you do not have to do anything - a daily backup runs on
its own and every archive is checked to make sure it really contains your data
before it counts as a success.
There is also a restore tool, which did not exist before. And this is the part
worth two minutes of your time:
php tools/restore.php --drill
Point it at your newest backup and it will restore that backup into a temporary
scratch database, tell you how many tables and rows came back compared to what
you have live, then delete the scratch copy. Your real database is only read,
never modified. It answers the question "would this backup actually save me,"
which is not a question you want to be asking for the first time during an
actual emergency.
Thanks for sticking with this. Four rounds of "it's still broken" is a lot of
patience, and every round found something real.
Eric