Why do we use PHP with an HTML web page? Lots of reasons, but data access is one of the most important, and PHP Data Objects (PDO) is, for me, the best way to do that.
There are lots of web languages out there, aren’t there? HTML5, JavaScript, PHP, CoyoTE. I actually don’t know if that last one exists, but given the number of special languages available for the web, I think I’ve got a 50-50 chance.
And increasingly, on the IBM i, we are being introduced to—and find reasons to use—more and more of these languages. Each has its own list of things that it does well and things that it doesn’t.
That is, HTML5 by itself allows you to script pages but not to access data from files. Similarly, JavaScript, for all the wonderful things it can do on the display side, can’t access tables. Duh, it’s a client-side language, like HTML5. But unless you’re accessing data on your own PC, your data is being stored in a server somewhere. So you need a server-side language.
Ta-da! (PHP enters stage left, looking heroic yet humble).
Fortunately, PHP is a server-side language and one that is ideally suited to doing data access types of activity.
A brief aside at this point. If you’re building an app on your i that interfaces with the web, you don’t have to do the data access portion with PHP (or any other web language). If you build your app in a Model-View-Controller (MVC) fashion, then you could write the Model part (the one that contains the data access routines) in RPG and avoid having any data access in the PHP portion. You would still need PHP to wrap up the HTML5 that’s used for the View, but you wouldn’t have to use it for data access. But you might just as well decide to develop your app entirely in PHP or do the Model part using PHP, in which case you would need the data access ability. Just wanted to make sure that was clear. Lots of decisions to make. Anyway, sorry to digress. Carry on.
PHP Database Access
Unlike RPG, where we tend to use only one database, things are much more wide open in the web world, where we might use a wide variety of databases. Each one is different, of course, so a single set of I/O-type routines will not work. We need something that’s tuned for an individual database.
Of course, MySQL is one of the more common databases used with any web language, and PHP certainly supports the ability to access a MySQL database with actually two API sets.
The first is mysql_*. This is a very simple API with operations like mysql_connect, mysql_fetch, etc. Its advantages are that it’s easy to use and very well-known, so it’s easy to find folks who are familiar with it.
It does have its disadvantages, of course, and a newer API to access MySQL databases has been added to PHP: mysqli_* (mysql Improved). The result is that while mysql_* has not been officially deprecated, it’s recommended that you use the mysqli_* API instead.
Mysqli_* offers a number of advantages over mysql_*, including the ability to support prepared SQL statements (which protects your app from SQL Injection hacking), enhanced debugging features, an OO interface, and other items.
But both of these API sets have one disadvantage for those of us in the i world: They both work only on a MySQL database. That’s a big disadvantage if you’re a web programmer, because even though MySQL is ubiquitous on the web, there are other databases, and if your app has any portability potential, you want to be able to easily switch from one database to another. And, of course, if you’re writing applications for the i, chances are that you will be wanting to pull at least some of your data from a DB2 database, which is definitely not MySQL.
Enter PDO
Fortunately, another option can be used with PHP: PHP Data Objects (PDO).
PDO is not part of PHP per se. It’s a bolt-on, but it has shipped with every version of PHP since 5.1. Bottom line, you don’t have to do anything special to get PDO to work as long as you’re using 5.1 or above. It requires some of the OO features that were added in release 5, so it does not work for PHP releases below 5. Essentially, it consists of two pieces: the core PDO functionality, and a set of PDO data-access drivers that are database specific. When compared with mysql_* and mysqli_*, PDO has several advantages.
The first is that PDO comes in a variety of flavors, supporting about a dozen or so databases, including DB2 and MySQL, thus making it ideal for an i app and doubly so for one that accesses both DB2 and MySQL data. Among the other databases it supports are Oracle, Firebird, Formax, PostgreSQL, and others.
The second advantage PDO has is that it incorporates a data abstraction layer so that no matter which database-specific version of PDO you’re using, the same routines are used to actually access the data. Only the command interface that you’re dealing with is database-specific.
The third advantage is that it’s extremely flexible. It can be used in both procedural and OO environments. It has very robust error-handling capabilities. And it provides all of the functionality you will need for your database activities, including prepared statements, commit, rollback, etc.
There Is Another
But wonderful as it might be, PDO has its own set of drawbacks, so we will look one more tool: IBM’s very own DB2 API set called, appropriately, db2_*. But that will be next month’s surprise.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online