I've been using TBS, OpenTBS and TbsSQL for several years now, always on PHP 5.3.x. I recently decided to try an upgrade to PHP 7.0, and have now run into a strange problem (an error, apparently, but not error text coming back, just:
[TbsSql][Error]: Database error message:
Has anyone else successfully used TbsSQL with SQL Server (the tbssql_sqlserver_odbc.php module, last updated in 2010) in PHP 7?
Is there some known reason why this might not work?
I think I figured it out, so I'll post what I found just in case someone else ran into this weird situation.
I'd apparently had a minor bug in my original code that was doing a $Db->Close() call before I was really done with the connection.
For some reason, in my old environment (where the only difference I think was that I was running a pre PHP 7 version (5.3 or maybe 5.6, possibly it behaves the same on both of those)), subsequent calls using the same $Db connection would succeed, even though, technically, it should've been closed.
As I said, I was using the tbssql_sqlserver_odbc.php module.
Anyway, in PHP 7, once I removed that incorrect Close call, my modules worked as they should.
It's probably a weird obscure situation, but maybe it'll help some one else out someday.
Further note: the symptom I was getting (which is probably generally true of TbsSQL calls, I suppose) is that a call to (e.g.) GetRow would return false instead of an array with the results, as usual.
Related
On my development server, I installed PHP (5.5), MySQL and Apache. The hosting company only supports up to PHP version 5.3.27. I don't really work in PHP, often so I might be missing something obvious here, but my problems are the following:
CakeSession::read('User.stuff')['more_stuff']; // works on 5.5
CakeSession::read('User.stuff')['more_stuff']; // syntax error on 5.3... wat?!
I managed to fix the above issue by assigning CakeSession::read('User.stuff') to a temp variable, and then accessing more stuff with $tmp['more_stuff'].
However, I have a bigger problem. I can't seem to access model names by their model name in arrays returned from databases. Namely, the following code stopped working:
$some_model['ModelName']['model_field']; //works on 5.5
$some_model['ModelName']['model_field']; //warning about 'ModelName' being a non-existant index.
When I try $some_model[0]['model_field'] it works just fine.
Cheers!
EDIT: Ok, turns out < PHP 5.4 doesn't support subscripting return values. Still weird, but it explains the first problem.
As you found out, array dereferencing with function/method call expressions is only supported as of PHP 5.4, nothing special about it, it's simply a feature of newer PHP versions.
Your other problem is most probably not that string indices magically don't work anymore, but simply that the structure of the array you are accessing is different.
Where this difference might stem from? Pretty hard to tell without any context. You should provide some code that can be used to reproduce your situation, and you should also do some more debugging on your own, trace back the function call flow and check at which point the data becomes different.
Oke, i've been busting my head on this one.
I'm gonna try and keep things short, however, if you need more info, don't hesitate to ask.
I've written an import repo for an external firm, so we can import their data into our service.
quick overview of implemented logic?
ftp, grab xml file, parse it with simple_xml and do db stuff using laravel eloquent component.
on my dev machine,
every run gets parsed fully and all data is inserted correctly into the database.
problem
when i try the same thing on my production server.
I'm receiving a duplicate entry error, always on the same exact record. (unless i'm using another file)
pre script setup to help detect the error
on each run i do the following:
make sure i'm using the exact same files on both dev and prod
environment... (i've disabled the ftpgrab and uploaded manually to
the correct location)
truncate all the related tables so i'm always
starting with empty! tables.
i've manually triple-zillion checked for duplicates in the xml, but they're not in there.... and the fact that
my dev machine parses the file correctly confirms this.
what i tried
at this point, i've got no more clues as to how i'm supposed to debug this properly.
by now, i've checked so many things (most of them i can't even remember), all of which seemed pretty unrelated to me, but i had to try them.
those things include:
automatic disconnects due to browser
mysql wait timeouts
php script timeouts
memory settings
none of them seem to help (which was exactly what i was expecting)
another fact
my php version on my dev is 5.4.4 and the version on the production server is 5.3.2 (i know this is bad practise, but i'm not using any new features, it's really dead easy code, though it has quite a few lines :-) )
i've been suspecting this to be the cause, but
i've now switched to 5.3.14 on my dev... still the import runs without an issue
the changes from 5.3.2 to 5.3.14 are probably pretty minor
i've tried to manually compile the exact same php version, but i'm to inexperienced to properly do this. moreover, it probably wouldn't have the exact same specs anyway (i think it's pretty impossibly to ./configure exactly the same, considering the use of MacOs vs Ubuntu? especially for a noob like me)
So i've abandoned this path.
I've tried to find the differences in the php versions, but i can't seem to stumble upon anything that might be the cause to all this.
there was a change related to non-numeric keys in arrays (or strings for that matter) in version 5.4.4 (i think) but since i've now come to the conclusion that 5.3.14 also works, this definitely is not the issue. --- looking around insecurely hoping not having said anything downright stupid ---
quick thought while writing this:
the thing is, even though i'm getting the duplicate error statement.
The record did get inserted into the database.
moreover, the error gets triggered when having processed about 2700 (of total 6000) records.
the bound data to the query is actually the data of the second record in the xml file.)
I'm sincerely hoping anyone could put me on the right track for this issue :(
If you made it this far, but don't have a clue about what's going on, thx for reading and sticking to it.
If you might have clue, please enlighten me!
I've written some PHP code to insert some data into a MySQL table using the mysqli extension and prepared statements. The MySQL server is running version 5.0.77.
I tested the code locally on my machine running version 5.5.27 and it runs perfectly fine. When I transfer my code to the server with the older version of MySQL, I get the error "Unknown prepared statement handler (0) given to mysql_stmt_execute" each time".
I've googled for this error a lot and only found bug reports which all seem to have been fixed before version 5.0.77. The other strange thing is that the reports sometime mention the number in error message changing, while in my case, the number remains constant at 0, regardless of how many different browsers I simultaneously open a connection from.
I can't upgrade the server, since it is not under my control, and serves a lot of other users as well.
Does anyone have any ideas what might be happening, or how to fix it? Thank you very much.
Edit
The PHP code is pasted at http://pastebin.com/1X4f5G5Z. I've added some comments that should help understand what the functions do.
I am using wrapper classes over the mysqli extention as provided at http://www.php.net/manual/en/mysqli-stmt.bind-param.php#110363
I tried a lot of things without any success. This is possibly a bug in MySQL v5.0.77.
I finally got my code to work by resorting to the workaround by #robert-rozas in the comments and migrating my code to mysqli extension, and now it works great! Reposting here to resolve the question.
I have created a website 3 month ago. I uploaded it to internet and it worked(it still works there). Now I installed it in my local computer and trying to access it. However it prints the following error messages multiple times:
Deprecated: Assigning the return value of new by reference is
deprecated in C:\xampp\htdocs\ptr\xajax\xajax_core\xajax.inc.php on
line 1258
Strict Standards: Only variables should be assigned by reference in
C:\xampp\htdocs\ptr\xajax\xajax_core\xajaxPluginManager.inc.php on
line 269
I am using XAJAX framework and the errors have something to do with this framework. Since I haven't changed anything in the library files, I don't understand what the problem can be. Please help... I am freaking out
The framework you are using seems to be a little bit outdated and uses such constructs
$x = & new Classname();
The & before new is deprecated since PHP 5.0 (which is several years old now). With the introduction of E_DEPRECATED- and E_STRICT-messages it throws such a message now.
Unfortunately this kind of statement are deprecated from PHP 5. In your local machine you're running a version which is 5.3 while your server is running an older version. Thus, on your machine is thrown a E_STRICT error. To avoid this problem, you have to change lines like:
$node_obj =& new someClass($somearg, $moreargs);
into
$node_obj = new someClass($somearg, $moreargs);
Xajax 0.6 targets this and a couple of other issues. When the development on xajax 0.5 started many users were still trapped on PHP4 Webservers and this syntax helped maintain compatibility for PHP4 up to 5.2.x.
Xajax 0.6 can be found on https://github.com/Xajax/Xajax-Project
Though it's still beta, it's already pretty solid. Many deprecated function were dropped and the core was shrinked & optimized.
Previous comments fully explain the source of those warnings. Your website will work fine despite of them. But you can disable PHP error reporting, if you want to hide these messages - this manual may help you: http://complete-concrete-concise.com/web-tools/how-to-turn-off-display_errors-in-xampp
(UPD: For your local version only of course)
I think I may have found a bug in PHP's crypt() function under Windows.
However: I recognize that it's probably my fault. PHP is used by millions and worked on by thousands; my code is used by tens and worked on by me. (This argument is best explained on Coding Horror.)
So I'm asking for help: show me my fault. I've been trying to find it for a few days now, with no luck.
The setup
I'm using a Windows server installation with Apache 2.2.14 (Win32) and PHP 5.3.2. My development box runs Windows XP Professional; the 'production' server (this is an intranet setup) runs Windows Storage Server 2003. The problem happens on both.
I don't see anything in php.ini related to crypt(), but will happily answer questions about my config.
The problem
Several scripts in my PHP app occasionally hang: the page sits there on 'waiting for localhost' and never finishes. Each of these scripts uses crypt to hash a user's password before storing it in the database, or, in the case of the login page, to hash the entered password before comparing it to the version stored in the database.
Since the login page is the simplest, I focused on it for testing. I repeatedly logged in, and found that it would hang maybe 4 out of 10 times.
As an experiment, I changed the login page to use the plain text password and changed my password in the database to its plain text version. The page stopped hanging.
I saw that PHP's latest version lists this bugfix:
Fixed bug #51059 (crypt crashes when
invalid salt are [sic] given).
So I created a very simple test script, as follows, using the same salt given in an official example:
$foo = crypt('rasmuslerdorf','r1');
echo $foo;
This page, too, will hang, if I reload it like crazy. I only see it hanging in Chrome, but regardless of browser, the effect on Apache is the same.
Effect on Apache
When these pages hang, Apache's server-status page (which I explained here, regarding a different problem) increments the number of requests being processed and decrements the number of idle workers. The requests being processed almost all have a status of 'Sending Reply,' though sometimes for a moment they will show either 'Reading request' or 'keepalive (read).'
Eventually, Apache may crash. When it does, the Windows crash report looks like this:
szAppName: httpd.exe
szAppVer: 2.2.14.0
szModName: php5ts.dll
szModVer: 5.3.1.0 // OK, this report was before I upgraded to PHP 5.3.2,
// but that didn't fix it
offset: 00a2615
Is it my fault?
I'm tempted to file a bug report to PHP on this. The argument against it is, as stated above, that bugs are nearly always my fault.
However, my argument in favor of 'it's PHP's fault' is:
I'm using Windows, whereas most servers use Linux (I don't get to choose this), so the chances are greater that I've found an edge case
There was recently a bug with crypt(), so maybe it still has issues
I have made the simplest test case I can, and I still have the problem
Can anyone duplicate this? Can you suggest where I've gone wrong? Should I file the bug after all?
Thanks in advance for any help you may give.
The bugs 51059 (only about passing invalid inputs) or 50947 (not the same code, 5.3 has new algorithms and features implemented in php, on all platforms) are not related to this problem.
However http://bugs.php.net/bug.php?id=51424 is. I already posted a partial patch there, but it solves most of the possible locks but it is indeed not sufficient. A full fix will be present in the next 5.3 release.
By the way, it is not windows specific but about the threaded SAPI (windows apache 2.2 for example).
This question has now been viewed 128 times and upvoted 9 times. The only answer I've received says it's a bug, and points to one in the PHP bug database. I don't think it's exactly the same one, but it does seem to validate my diagnosis.
Therefore, with some hesitation, I have filed a bug report:
Bug #51666 - Using crypt() makes Apache hang or crash
Thanks to everyone who has looked at this with me - even if you didn't reply, just knowing that others were considering this with me, and not telling me I'm crazy, has been helpful.
Yes. It's a known bug,
http://bugs.php.net/bug.php?id=50947
You can simulate the crypt() result using mcrypt. If you can change your password hash, you should really use hash_hmac(), which is more secure and we have no issues with it On Apache. No experiences on Windows though.