requinix

A tick happens every time the engine does something at a fairly granular level. Like executes a statement, but even lower-level than that. The easiest way to understand it is going to be to play with code: set up a ticket handler every 1/2/3/whatever ticks, have it output something, and then write a bunch of code to execute and see what happens.

Don't. PHP isn't a low-level language like C. You don't have to manage memory like that. PHP has some very smart internal logic and is perfectly capable of handling creating and destroying variables on your behalf. So let it do what it knows how to do.

if ($statu1 = "Online") { echo "<font color = green>$status1->nodeValue</font><br>"; } elseif ($statu1 = "Offline") { echo "<font color = red>$status1->nodeValue</font><br>"; } One = does an assignment, which means the above code actually works like $statu1 = "Online"; if ($statu1) { echo "<font color = green>$status1->nodeValue</font><br>"; So naturally, every status will be green. Two ==s does equality comparison. (Three ===s is if you want to be pedantic about what it means to be "equal".) if ($statu1 == "Online") { echo "<font color = green>$status1->nodeValue</font><br>"; } elseif ($statu1 == "Offline") { echo "<font color = red>$status1->nodeValue</font><br>"; } That aside, this is very outdated HTML 4-style markup. You should switch to <span>s and CSS.

Not having symbols is okay, it just means that gdb won't be able to fully translate the machine symbols it's reading into more useful, human-friendly symbols - like, parts of a backtrace will be cryptic. But it'll all still work fine.

I was following along until the "please do this for me" bit at the end. REGEXREPLACE + REGEXEXTRACT like that is silly. Not sure where you got it from, but a single REGEXEXTRACT is enough to extract all the <uppercase letter + stuff>s in the cell. Check the documentation/help docs for how to make it match everything instead of just once (which is what it does by default). For the regex part, it's currently doing <uppercase letter + lowercase letters> so naturally it will only work with lowercase letters and not with numbers or symbols. If you want to match things that look like <uppercase letter + stuff> then realize that "stuff" is a less precise way of saying "keep going until the next uppercase letter". Or in other words, "anything that isn't uppercase". Because computers need you to be precise if you want them to work a certain way. Excel's regex syntax for "anything that isn't ___" is the same as everybody else does it, so you can check either the docs (which I'm sure include a little bit of regular expression syntax) or virtually any other regex resource to find how to write that.

There was nothing "kind" about the volume of spam you just sent out. Please use the existing account tools to request a deletion of your account.

It worked for years even though it's clearly missing a comma at the end of the first line?

Did you run gdb the same way as you had before? Did you get the same output (before the bt step) as before, including the part where it says there was a segmentation fault?

I'm pretty sure you're encountering https://github.com/mdbtools/mdbtools/issues/312. Good news is that it was fixed, bad news is that it was fixed in mdbtools 1.0.1 and Ubuntu 24.04 currently only covers through 1.0.0. There might be a third-party PPA out there that has an updated version, but I don't know where to look for one. Or you could venture down the path of building it yourself, if you wanted: grab the Ubuntu sources, patch them according to this PR, and build. Or for a workaround, I think you'll be safe as long as you're not SELECTing anything that requires 64-bits of data length - meaning a VARCHAR(16777215) is okay but a VARCHAR(16777216) is not.

I did. I can never remember which systems allow for quoting identifiers with apostrophes or quotation marks.

I don't think backticks are the right quoting style, but brackets should have been. Or maybe not. Try single and double quotes too. Been a while but I think the LIMIT could be a problem too. Does SELECT TOP 3... instead work?

That insane number for how much memory it tried to allocate strongly indicates an internal problem. But with both pdo_odbc and the plain odbc extension? Now I'm suspecting MDBTools is the one at fault. Are you using the latest version of that? Can you identify exactly which column(s) is causing the problem? What data type is it? Are you able to run SELECT queries on other tables that have a column of the same type?

Looks good. I think you might be running into a bug related to this one, which seems like it was fixed in the v2.3.12 you're using so it's probably not that exactly. One way or another, the problem does seem to be about connection pooling. Pooling won't gain you anything on the CLI so try disabling it.

Almost there. Do that, then when you get the gdb prompt enter "bt" and it will dump a bunch of numbered lines. So far, though, it looks like the problem is in unixODBC, which is surprising as you're already on the current version - that said, it's been a couple years so I'm not sure it's still maintained...

Yeah, it's called "the internet". There's a whole bunch of it out there.