-
So you didn’t run it through several thingies; you ran part of it.
-
Try BBedit on the Mac, that can show invisibles.
Did you selected anything? If not use Select All an then bring that menu back up
Thanks, that did it. Learned something new!
I think it should act as if it’s all selected if nothing is selected.
3 Likes
Benjamin,
Good that it’s solved. If may add a suggestion: Place the sql in a constant. That way you can format it so it’s readable, and you can copy it directly to/from whatever database tool you use (watching out, of course, for hidden characters).
Have in mind that Xojo does not respect what you paste into Constants, I found it kills the Line Feeds and replace them with Carriage Returns for instance, and this can cause bad side effects if you have multiple statements, for example. You must post-process your SQL with something like sql.ReplaceLineEndings(EndOfLine.Unix) to avoid such problems.
Note that I’ve had zero problems with this, and I create constants with EOL’s all the time. Test to see if this affects you.
1 Like
You haven’t, and I had. The fact is the Constant is not Constant, it changes by itself, we already have a discussion about it, and I proved that fact. To be true, anyone can easily check this. The workaround is what I said, post-process the damaged Constant with sql.ReplaceLineEndings(EndOfLine.Unix) to avoid such problems.
I can’t reproduce this. On Windows and Mac, the EOL character from a constant is linefeed.
Well, maybe the defect shows only in the Windows IDE?
I do write 3 SQL lines in VS Code, with LF set as EOL. Copy, paste anywhere, the LFs are there. Paste into a Xojo Constant, all LFs becomes CRs and we see them debugging. If I set VSCode to EOL = CRLF, copy, paste into a Xojo Constant, all CRLFs become CRCR. So some SQL engines, like SQLite, see the multiples lines as a huge one line, because they only care about LF, and CR is the same as space, and if it has comments, it breaks the SQL, and maybe it does some silent terrible fails. sql.ReplaceLineEndings(EndOfLine.Unix) workaround it inserting LFs back.
Yes, I am seeing that, EOL is returned as &u0D on Windows, &u0A on Mac.
Again, this may or may not matter, so the developer should test. Or follow Rick’s advice in all cases and ensure the EOL’s are what you want.
I do write multi-platform code, it must work anywhere without fail. So the workaround is IN the code, with the broken constant, and post processing with sql.ReplaceLineEndings(EndOfLine.Unix), because you, Kem, said it was the way of doing it in Xojo, and passed all the old thread saying that that CRCR bizarre transformation behavior was a correct Xojo behavior. Happy to see you weeks/days later “kind of” accepting the fact.
Please do not sidetrack the thread. It’s been resolved, and you’ve made your point.
Point of view, for me you were sidetracking it. But we are all set here.
@Benjamin_Brannen any way to know at this point what the invisible character was specifically? The IDE already has safeguards in place to prevent this so knowing the exact character would help prevent it from happening in the future.
You can copy Benjamin code from the original post, it has the invisible character there.
I don’t know much about invisible characters, this is what Xojo reports that sql has in hex:
hope this helps.
It does. I think that’s a BOM, but will have to check.
I think you are right
EFBB that would be UTF-8?