On The Periphery

Just recently, I am finding that I am using SQLite more and more often as the development database. There are a number of benefits using SQLite:

1. Portability

I can easily transfer the database around with my code. It is a single self contained file, I dont need to worry about the database engine configuration.

Anyone who has tried installing XDebug, to help debug PHP, will attest to the fact that it's it not the simplest task in the world.

That may be a little harsh, the actual installation is quite simple, it's the chosing of the correct file to download thats confusing. When downloading the file you need to make sure that all of the following matches (especially for a windows installation):

• PHP version
• C compiler - the compiler used to compile PHP
• 32 vs 64 bit version

You then need to update your PHP.ini file.

Appologies for the recent dead air, we here at Veraida have been trying consolidate a number of our servers. As part of the consolidation, we have chosen to host all of our Drupal sites off one multi-site installation of Drupal.

This required us to update all sites, so that they were all running on the same version of Drupal - something which we have since found out is easier said than done. Especially when we had bee neglecting out internal sites (they weren't broke, so no reason to update them)!! Thus OnThePeriphery was updated 2 major versions (from 4 to 6).

I think that I have finally settled on a consistent framework for most of my future PHP development – Kohana.

I have used Symfony, CakePHP and Zend but have not used them deeply enough to go into a proper comparison.  All of the frameworks seem well written and fulfil the purpose of rapidly creating a MVC application. 

So why did I choose Kohana?

I found myself working on another inherited application this week. As it with all inherited applications, especially ones as old as this one, the processes around deployment were a mess. In fact, most deployments had been done by hand with no standards around the deployment location. How was I supposed to write an upgrade for an application when I didn’t even know where it was installed?

At least the ActiveX DLL’s details were in the registry – retrieving them was a pretty simple two step process; you just need to know the name of one of the classes within your DLL.

Many people have requested the ability to run an SQL file, which holds multiple commands.  As the developer states, this is not really possible as the plugin cannot really deal with multiple result sets and errors.

This would be extremely useful, especially when doing a fresh installation of an application.  All of my application installations install the databases from script, for a number of reasons:

• Easier to do remote DB setup
• Easier to keep code under version control

I have recently become an avid fan of NSIS, the Nullsoft Installer Script. It is an extremely powerful way of creating installers, as it gives you control over almost every aspect the installer. Coming from a PHP/C#  background, I have also found it fun learning the quirky ways of using NSIS and am still not sure that I am doing things quite right.

I recently received a a large text file (many megabytes) which was a concatenation of many different smaller files.  The smaller files where of different size and the separated by a particular character. I did a quick Google search, but almost all of the file splitting applications available split files based on size.

I needed to split a file based on a certain ASCII character.

Once I got the initial data transfer up and running, I needed to place the whole thing into a transaction, I was doing multiple table transfers (with some data manipulation).  I could not have half a database transferred, even if I did throw an error.

I simply threw in an SqlTransaction, and made everything run inside that.

However, I hit an exception when using the SqlCommandBuilder to create the insert command: