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
Related
Can I somehow detect how much MySQL queries performed via old mysql and how much via mysqli connections.
My basic work is recode, refactor and support old projects. I migrate from procedural to OOP style and from mysql to mysqli. I need to know how much old requests left from old coders (code is messy and crazy as usual to calculate this in code directly).
Thanks!
mysqli has http://php.net/manual/en/mysqli.get-connection-stats.php
and for any driver you can run show status like 'Com\_%'; query.
I see no point in such numbers though, for the task provided.
You can override both methods with override_function and log whatever you need.
I'm working on a university project at the moment and they've informed me that they won't support mysqli in their hosting environment.
While this seems a backwards decision to me, it's what I'm dealing with. Is there a way to handle transactions in MySQL using the old mysql library?
We have a volatile process involving student data that really needs transaction handling. The process was written by students years ago and is naturally prone to errors. All of it was written with mysql functions until I converted them to mysqli. We don't have time or budget to refactor the whole thing, so I just need a way to get transactions working again. Thanks!
you do not want to go back to the old mysql as it is being taken out of PHP for a reason.
Look into PDO: http://php.net/manual/en/book.pdo.php
And you will soon find yourself completely falling in love with this one. It exceeds mysql and mysqli by far, and your university will be happy to see this coming in
Transactions in mysql are handled by means of simple SQL commands like START TRANSACTION and such. You are allowed to issue these commands from client using whatever API you like.
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 read that although SQL is meant to be standardised, it is implemented different etc with different databases. I have only ever used MySQL for databases.
What I would like to know is what other databases share the same syntax? I am using PDO now, and I would like to set a flag to allow the user to specify which database they would like to use.
I would be interested in knowing which are the 'safe' databases that will handle most (if not all) my general MySQL queries. Mainly SELECT, INSERT, UPDATE, DROP, DELETE.
Thanks
There are several revisions of a such called ANSI SQL.
All major database engines (that is Oracle, MS SQL, PostgreSQL and MySQL) should (should) in theory support SQL-92.
This includes everything you've mentioned: SELECT, INSERT, UPDATE, DROP, DELETE, as long as you don't use complex clauses with them.
In practice:
Not all databases support the full set of SQL-92.
Writing cross-platform SQL even in SQL-92 requires lots of testing.
Platform independency in SQL ends when you insert your 1001st row and need to optimize you queries.
If you browse a little over StackOverflow questions tagged SQL, you will see that most of them say "help me to optimize this query", and most answers say "use this platform dependent hack"
You will find that some database store datatypes differently, for example, mysql stores Booleans as 1 and 0 and postgres stores them as 't' and 'f'.
As long as your database classes are aware of the need to convert data, you should be fine, probably 96.3482% of everyday CRUD will work pretty well across the board.
Even if you create database classes that directly call PDO, you can later on add some logic for data translation or query modification.
You could use the database abstraction layer ADOdb. (its got what plants crave)
I'd suggest making sure that your customers actually give a crap about which database they need to run before you spend a lot of time developing functionality you may not need.
A standardized SQL92 is pretty much the same in all RDBMS. The differences are in parts, that the standard doesn't define, like for example LIMIT or datetime handling functions and of course procedural languages.
As for DBs popular with PHP: it not that hard make SQL portable between MySQL, SQLite and PostgreSQL. It won't be that easy with Oracle, Sybase and DB/2.