Update 21_1_25 broken...

I have uploaded a screenshot of the issue. I modified the results to show the structure and content variables also. The issue is that "bRollback" is TRUE and it always rolls back, but no errors are logged. Is something missing which sets bRollback to FALSE? Again, the other updates worked, although 24 and 25 both have a space or some other character as the first character in the file. I have to delete this invisible character or the update will not run at all. I am guessing these were written in something in Windows which is not unicode aware?

I found the issues. You can't do safe updates without specifying an index. I removed all commenting, coding, everything except SQL from the update and ran it. It ran until it hit the following lines.
[code]
update dbdocsfields SET FieldComment = replace(FieldComment, 'table', 'table');
update dbdocsfields SET fieldNotes = replace(fieldNotes, 'table', 'table');
[/code]
There is no index given so it was failing due to not being a safe operation. This was not being shown in the errors log, but it was causing the rollback flag to trip. All updates MUST specify an index! I now have to delete everything up to this line and figure out how to correct it so I can complete the update.

I disabled all the safe update features on the server and was able to execute the two lines of code and the other remaining 126 lines. All is good now, but there has to be a WHERE clause in these updates. I turned my safe updates settings back on after updating to 21_2_1. I am good and can continue work on the server, but something should be done about this. I will leave this open since the issue has not been fixed.

[quote=Xenithar]I found the issues. You can't do safe updates without specifying an index. I removed all commenting, coding, everything except SQL from the update and ran it. It ran until it hit the following lines.
[code]
update dbdocsfields SET FieldComment = replace(FieldComment, 'table', 'table');
update dbdocsfields SET fieldNotes = replace(fieldNotes, 'table', 'table');
[/code]
There is no index given so it was failing due to not being a safe operation. This was not being shown in the errors log, but it was causing the rollback flag to trip. All updates MUST specify an index! I now have to delete everything up to this line and figure out how to correct it so I can complete the update.[/quote]

To make these lines safe add an "always true where clause", involving an index, like you did in a previous PR (21_1_16, if I remeber right). Like:

update dbdocsfields SET FieldComment = replace(FieldComment, 'table', 'table') where `fieldId`> 0;
update dbdocsfields SET fieldNotes = replace(fieldNotes, 'table', 'table') where `fieldId`> 0;


This is a standard procedure to calm down the angry MySQL.

PS: What is the meaning of those 2 updates? Maybe I`m blind, but I don't get it. It replaces all occurences of "table" with.. "table"? In the comments I see something about "fixing a typo"...

Yeah, I did not understand what it fixed, but left it alone. I thought about doing a PR for >0, but wanted somebody familiar with why these lines were even in there to comment first. They appear to do nothing.

[url]https://github.com/mangoszero/database/pull/31[/url]

Lines removed.

They were supposed to replace 'tabel' with 'table', but that spelling error no longer exists. I have no idea how both fields in that script ended up as the same.