I'm using Laravel 5.1 on Ubuntu PHP5.6 and the GUID to string conversion is working just fine. However on my development environment in PHP 7 it's pritining out like how it used to when I had to use the old mssql driver that came with php.
So all my string comparisons are failing on 7 for GUID's saved in mysql.
My gut says that some PDO setting that's not being set correctly. The query in question is using the DB class to fetch data through a raw sql. I think Eloquent is rendering correctly, I've not seen this problem before and I've been using it throughout (this is an older code base before I leaned additional tricks I currently use to work with this database)
Any ideas where I can start looking.
Turns out it was the particular set of credentials and set up for the software that was causing the byte problem. I was logging in fine but changing the connection string fixed the problem.
Related
Recently I have migrated one of my projects (PHP 7.4/Lumen/Ubuntu 20.04) from MongoDB to MongoDB compatible AWS DocumentDB. Since the migration all the CLI Scripts are triggering this strange notice/warning
bson_append_array(): invalid array detected. first element of array parameter is not "0".
Everything seems to be functionally working apart from this message (Even though I have all the PHP errors hidden from ini file this still shows up). Not really sure what is going on.
Message is actually coming from "find" method. I also did try to suppress the msg but no luck.
Does anyone have any idea what is going on here ? Appreciate and thanks for all your responses in advance.
DocumentDB version 4.0
PHP SDK Composer version 1.9.0
If you add &authMechanism=SCRAM-SHA-1 to the connexion string, the warning disepear.
I am answering my own questions based on my findings so far.
Seems like there is no solution for this issue since AWS DocumentDB is not 100% compatible with MongoDB (As per mongoDb documentation over 66% of all of the correctness tests have failed for DocumentDB). Also it is extremely difficult get AWS support for these sort of incompatibility issues, they always refer you to public user forum.
MongoDB recently put up a blog post summering incompatibility issues with DocumentDB and it makes a lot of sense. You can read it in detail here - https://www.mongodb.com/atlas-vs-amazon-documentdb/compatibility
My recommendation is if you are considering using documentDB as a replacement of Mongo do not bother. Save your precious time by sticking with MongoDB.
I am migrating an extension I wrote (started back for 6.2) to TYPO3 9.5.
I already had it running in 9.4.
Since I updated to LTS I can not get any translated values from the database.
The repository queries I am using are straight out of the extbase box (e.g. findByUid())
On the translated pages i get the desired results for standard content elements of TYPO3.
In the upgrade docs I found the "Important 82363" section, which says, that some changes have be done to localization but as far as I understand it, that only matters if using languageOverlayMode or languageMode. I don't use either of them. But setting the TypoScript switch
config.tx_extbase.features.consistentTranslationOverlayHandling = 0
gives me back my translations as they have been before 9.5.
But since this is only a temporary solution I need to find out, where my problem lies.
(Querying the querySettings gives me the results I expect; also the correct languageUid is displayed - but not used)
Thanks
This is a bug in TYPO3 extbase itself, see the issue https://forge.typo3.org/issues/86619 and the changes (which are not yet merged) at https://review.typo3.org/#/c/58635/.
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.
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.
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.