<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Wed, 22 May 2013 22:16:02 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Maggie Nelson's Blog: When PHP and Oracle assume the worst about each other]]></title>
      <guid>http://www.phpdeveloper.org/news/8037</guid>
      <link>http://www.phpdeveloper.org/news/8037</link>
      <description><![CDATA[<p>
As <a href="http://benramsey.com/archives/php-and-oracle-manual/">mentioned by Ben Ramsey</a> today, <i>Maggie Nelson</i> bumped into an issue in one of her applications with character sets and the incorrect storage/retrieval of information:
</p>
<blockquote>
Even Oracle, which usually gets storing of data right on the money has had issues with character sets. [...] Needless to say, even when you *know* you set up your database correctly for supporting UTF8, the path to debug issues may be frustrating and full of red herrings.
</blockquote>
<p>
She <a href="http://www.objectivelyoriented.com/2007/06/when_php_and_oracle_assume_the.html">mentions the setup</a> the application is using (NLS_CHARACTERSET AL32UTF8, NLS_NCHAR_CHARACTERSET AL16UTF16) but something wasn't right. The problem popped up when they tried to store Chinese characters into the database with the result of invalid data on a select. 
</p>
<p>
After following several different leads, they finally came upon the culprit - the Apache process didn't have the access it needed to a directory in the ORACLE_HOME. In the end, it all only broke down into three easy steps to fix a very frustrating issue.
</p>]]></description>
      <pubDate>Wed, 13 Jun 2007 10:10:00 -0500</pubDate>
    </item>
  </channel>
</rss>
