I have a database PHP application that can work with MySQL, PostgreSQL and SQLite. The application uses PDO and assumes the database content is Unicode.
I am adding the support for MS SQL SERVER using the pdo_sqlsrv driver and the only solution I have found is to modify all the queries (it's really a lot of work) adding the N prefix in front of the strings for the INSERT and UPDATE queries.
Is there any smarter solution to insert unicode by default? Like a PDO or SQL SERVER setting?
Since all the queries are executed by a function (it's my own layer over PDO), I have also thought about adding a regular expression that modifies the queries before the execution but I think it's quite tricky.
Thanks.
After you set up your connection to the DB you need to add the PDO Attributes:
$mssql_connection->setAttribute(PDO::SQLSRV_ATTR_ENCODING, PDO::SQLSRV_ENCODING_UTF8);
Reference:
https://learn.microsoft.com/en-us/sql/connect/php/pdostatement-setattribute?view=sql-server-2017
Related
I was reading this question:
The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead
And it got me thinking that I should make the change from mysql to mysqli. It is a one character change in CodeIgniter so it isn't very hard :)
But is there anything I should look out for to spot any errors that can happen? Are there certain queries that are treated differently?
Are there certain queries that are treated differently?
No.
The MySQL and MySQLi extension are “drivers” that take care of the communication between PHP and the MySQL database server;
they do not change the range of SQL commands that the MySQL server understands.
So as long as the DB abstraction layer takes care of what PHP functions are to use for what purpose for you (and a framework like CI should most certainly do that), there is nothing to worry about in regard to the actual queries.
As i am having tons of issues trying to work with ODBC for several weeks, like this one (Not able to perform a PDO Prepare Statement) i was looking for another solution.
I found that i can bind a VisualFoxPro database to a SQLServer. I have no idea about SQLServer so before i put my hands on learning some SQLServer i have a few questions about this.
If i bind a VisualFoxPro database to SQLServer can i INSERT data to SQL Server and it will be added to VisualFoxPro... or will only work to retrieve data?
maybe this way i could create prepared statements and transactions?
Thank you
You can "upsize" foxpro tables to SQL which will duplicate the functionality of a Visual FoxPro database as closely as possible. You can also redirect Visual FoxPro views so that they use the newly created remote data instead of local data. With that being said, it is a pretty complex process (at least in my opinion), and depending on the size of your tables can take quite a while. You can read up on it here and here for starters.
I would suggest giving OLEDB drivers another look for your issue before you try to convert databases.
Chris
I'm creating a tiny activerecord library using PDO and I'm planning to support MySQL, Sqlite and PgSQL.
My question is how I can be sure that the query string works with all adapters? There will mostly be CRUD statements with some joins etc. Is there a standard I can follow that works for all of these?
Thanks
/ Tobias
EDIT: Thanks for all your answers but my question was more about the SQL 'syntax' differences between them.
If you want to write your own DB layer, I'd suggest you:
Use placeholders, if you aren't already. They add security too.
Use bindParam/bindValue with value type (e.g. BOOLEANS don't exist in SQLite but work if bound with PARAM_BOOL)...
Use stored procedures from MySQL, create matching names in PostgreSQL, and define them in SQLite with sqliteCreateAggregate/sqliteCreateFunction.
Do all parameter checking in PHP, because SQLite won't do any (e.g. validate date variables)...
Use InnoDB for MySQL to get transactions.
Note: By supporting these vastly different RDBMs, you're demoting the database to just a data store. Keep in mind that SQLite is very limited. It does not have native data types save from number/string. E.g. it's missing date handling and intervals, and so on. All three databases support transactions, which are essential for data integrity when the integrity is maintained outside the DB.
Edit: Removed mention of MySQL triggers, which are availabe for 5.0.
Here you have a simple introduction to zend_db_adapter - i think you want something similar (I posted this just as a example to see how others resolve the problem you have)
My choice for this kind of issues would be ADOdb. While I never actually used it with PostgreSQL, it just saved my sanity in a project that happened to be born with MySQL and then migrated to SQL Server, to SQLite and back to SQL Server.
Different databases have slight variations in their implementations of SQL. Does PDO handle this?
If I write an SQL query that I use with PDO to access a MySQL database, and later tell PDO to start using a different type of database, will the query stop working? Or will PDO 'convert' the query so that it continues to work?
If PDO does not do this, are there any PHP libraries that allow me to write SQL according to a particular syntax, and then the library will handle converting the SQL so that it will run on different databases?
From PHP manual :
PDO provides a data-access abstraction
layer, which means that, regardless of
which database you're using, you use
the same functions to issue queries
and fetch data. PDO does not provide a
database abstraction; it doesn't
rewrite SQL or emulate missing
features. You should use a
full-blown abstraction layer if you
need that facility.
So,you can not change the database and expect that everything works as before. It depends on the queries you have used. Are they "simple" SQL92 queries or do they use special features for a specific db...
Ex a mysql query with "LIMIT 10,20" must be rewritting to work with an Oracle DB or Sqlite. They use "LIMIT 20 OFFSET 10"
PHP doesn't have libraries that will automatically convert SQL for you. If you want that kind of functionality you should look at an ORM implementation like Doctrine. There is a price to pay of course, since there is a learning curve involved in using it in your project, plus writting SQL stops being as simple as churning out a string. You should ask yourself if you absolutely positively need code that's database independent.
I've got a site that requires manual creation of the database tables on install. At the moment they are saved (along with any initial data) in a collection of .sql files.
I've tried to auto-create using exec() with CLI MySQL and while it works on a few platforms it's fairly flakey and I don't really like doing it this way, plus it is hard to debug errors and is far from bulletproof (especially if the MySQL executable isn't in the system path).
Is there a better way of doing this? The MySQL query() command only allows one sql statement per query (which is the sticking point).
MySQLi I've heard may solve some of these issues but I am fairly invested in the original MySQL library but would be willing to switch provided it's stable, compatible and is commonly supported on a standard server build and is an improvement in general.
Failing this I'd probably be willing to do some sort of creation from a PHP array/data structure - which is arguably cleaner as it would be able to update tables to match the schema in situ. I am assuming this may be a problem that has already been solved, so any links to any example implementation with pro's/con's would be useful!
Thanks in advance for any insight.
Apparently you can pass 65536 as client flag when connecting to the datebase to allow multi queries, e.g. making use of ; in one SQL string.
You could also just read in the contents of the SQL files, explode by ; if necessary and run the queries inside a transaction to make sure all queries execute properly.
Another option would be to have a look at Phing and dbdeploy to manage databases.
If you're using this to migrate data between systems, consider using the LOAD DATA INFILE syntax (http://dev.mysql.com/doc/refman/5.1/en/load-data.html) after having used SELECT ... INTO OUTFILE (http://dev.mysql.com/doc/refman/5.1/en/select.html)
You can run the schema creation/update commands via the standard mysql_* PHP functions. And if the query() command as you call it will allow only one statement, just call it many times.
I really don't get why do you require everything to be in the same call.
You should check for errors after each statement and take corrective actions if it fails (unless you are using InnoDB, in which case you can wrap all statements in a transaction and rollback if it fails.)