I have a database in Access I need to access a Microsoft Access database via the internet and am building a PHP interface. I would like to know if it would be better to convert to MySQL or Microsoft CRM Dynamics as would they be faster?
My other question is can MS Access or MS Dynamics even be accessed via PHP PDO currently? If not my first questions is redundant and MySQL is the way to go.
Regards,
Max
Short answer:
it certainly makes sense to migrate your data into a normal relational database system, regardless if that is MariaDB, MySQL, PostgreSQL or whatever. Many advantages exist besides performance, for example you get rid of the vendor lock in and have free access to your data the way you want to. This includes using php to access that data. Is there any reason against migrating it? I mean reasons expect "we always used MS-Access" or the like...
And I never heard of a reliable and stable MS-Access driver for PHP.
Related
Problem:
I am building a RESTful API. The DBA I'm working with has set up an MSI for gaining access to the production database, which is on an Azure SQL instance. I understand that MSI's are token based, and on https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/tutorial-windows-vm-access-sql, it has an example written in C#. This does not translate to PHP well, mostly because of my unfamiliarity with C#.
In addition, I am using Lumen to develop the API, which uses PDO for handling the connections. As far as I know, PDO does not have the necessary functionality built in to handle the specialized connection string Azure SQL requires for using an MSI. See Azure Sql Db connection string when using MSI
Previous research:
I've read just about every article Microsoft has published about managed identities, and scoured the internet for anyone using managed identities in PHP. Needless to say, the pickings are slim, even more so for this particular use case.
I understand that one could use Key Vault and store the connection string as a note, but I'm 99% sure the system admins won't want this to happen. What's the point in having the MSI if we're still going to have credentials stored somewhere else?
Worst case, I suppose I could make the proposition that I need to use a traditional user/password auth flow, despite the powers that be wanting all new projects to use MSIs (we're predominantly a Microsoft shop with a small portion of PHP work).
Posting this is my last ditch effort before presenting my proposition to use Key Vault instead for, at very least, storing the production credentials; the idea of storing a connection string is an anti-pattern in my opinion.
Fundamentally, if someone could provide an example PDO connection string (sqlsrv driver) using an MSI, it would probably move me in the right direction. Any other examples one could provide, or even guidance for how I can use the MSI in this context would be greatly appreciated.
Per https://learn.microsoft.com/en-us/sql/connect/php/azure-active-directory?view=sql-server-ver15, PDO does have the required functionality. Answering this as the scope of the original question has shifted too far from its original focus.
I now have a support question opened at https://github.com/laravel/framework/discussions/33678 to determine the best method of utilizing an MSI in Laravel as there is no apparent way to do so based on the code/documentation.
I'm trying to connect a web portal coded in PHP to a Sharepoint database. I researched and there are 2 possible options to use: MSSQL 2005 OBDC Driver and Webservices.
Which of this 2 options is the better one, and why?
https://technet.microsoft.com/en-us/library/cc793139(v=sql.90).aspx
This is an easy answer. The answer is the web services because directly querying SharePoint's databases is not allowed from a supportability standpoint (reference: https://blogs.msdn.microsoft.com/brian_farnhill/2013/12/04/directly-querying-sharepoint-databases/)
To summarize some of the core arguments is that directly talking to the database (even if it is just reads) introduces unpredictable locking of database resources which will cause problems. On top of this, the Content Database schema is not the best of my knowledge formally documented and of course subject to frequent changes. If you've ever peered inside you'll see that it is quite complicated and thus difficult to come up with generic SQL to get the data you want. The API (and therefore the web services) have done the hard work to give you a generic interface into SharePoint and to hide the complexity.
Lastly, if you are at all thinking about modifying SharePoint you are an absolute glutton for pain if you think about using direct SQL.
Next month I need to develop a script to connect to an AS400 and query some data (>1000000). I want to do this with PHP, as I am doing a lot with PHP.
My question know is, how should I connect to the As400. I know that there is ODBC, but everyone said to me ODBC is sub-optimal because it cannot handle large dataset with a great performance. Everyone recommends me JDBC.
So what do you recommend me. What would you use if you get this task... I do not plan to switch the programming language if it is not as must.
I don't know about performance on ODBC and if there are differences based on the platform you are running it against, but I believe ODBC is the only way you can connect to the i with PHP if you are using PHP on a remote server. I do know that the i can handle large amounts of data much better than most other SQL database servers.
You could also ask this question on Web400 at Midrange.com. There are several on that list that use PHP and there are even a couple of people from Zend on the list that could help you out.
The IBM i (current name of platform) has database drivers for .NET and Java.
It may be that the DB2 universal driver for your platform can connect to the system, but I do not have personal experience with that.
I have to access and write to some berkeley db files that other applications share.
I really haven't found anything out there about using this with PHP. It really doesn't seem very popular.
Does anyone have any links or resources that I might be able to use to get things rolling?
Thanks!
Isn't this what the dba functions are for?
http://php.net/manual/en/book.dba.php
I've had some code some years ago with that. Didn't use it much however, because it was a somewhat inefficient data store. And it seems kind of pointless in the light of SQLite now anyway. But btw: http://schlueters.de/blog/archives/134-Berkeley-DB-5-and-PHP.html
Berkley DB isn't really meant for multi-user access. It is much better for an embedded database that is accessed by one process.
PHP processes run asyncronously on the web site. This means a php script accessing a Berkley DB has to rely on file locking to handle concurrent access.
This is very inefficient. thus no BDB support in php.
If you want to use BDB in a multi-user environment, you should write a web service in perl/c/python/etc that talks to BDB, and accepts connections from php. Or you could just use a real db server like mysql, postgres or something and save yourself the headache.
Can any one suggest me a good framework for working with SQL Server or Oracle.
Have you looked at the SQL Server and Oracle extensions for PHP? This would be the obvious way of working with SQL Server and Oracle from PHP.
You could also try the PDO extension for PHP. It provides a consistent interface for working with different database engines. It has support for both SQL Server and Oracle.
If you are looking for a way to connect to, and modify your database with PHP, something I use and recommend is the ADOdb library ( http://adodb.sourceforge.net/ )
It allows you to abstract the database calls and use common functions for your application that are not database specific. I like this approach as I work on multiple projects that have different database requirements and it allows my code to be more portable, meaning no matter what database I am using, the code never has to change if I want to reuse it.
It also helps with code consistency across projects, and over time will help you maintain those apps more efficiently as they using a "standard" way of doing things.