なかなか魅力的な価格設定です。

マニュアルをみると、「resource 型以外の任意の型」とのことだが乏しい知識ではよく理解できず、配列との関係がわからない。
そのため、トライ＆エラーで最初の結論にいたった。

今回、jqGridを使おうとしてDemoサイトを参考に自サバに設置するときにぶつかった問題。

見つけたサイトはこちら。

PDOのLIMIT句が動作しない

ここによると、phpのバージョン5.1.xでバグってたのを5.2.0で修正したのに5.2.1以降エンバグして5.2.6で再び直ったっぽいとのこと。

確かに、5.2.5での問題だった。

当時動作させていたテスト環境は、おそらく5.2.6。（今はなくなってしまって未確認）

ひとまずphpとしてはこれで解決。

だけど、自分がよくテストに使うCentOS5.2ではデフォルトでphp5.1.6。これを5.2.6へアップするのは面倒くさいなぁ。

早くCentOS5.3＋php5.2.6とかでてこないかなぁ。

マイホームへ戻って、「友達を招待」をみると招待中の一覧には登録されていた。

そのエラー文言はこちら。

Warning: mail(): Could not execute mail delivery program ‘/usr/sbin/sendmail -t -i’ in /home/ACCOUNTNAME/domain/OpenPNE/webapp/lib/util/mail_send.php on line 60

Warning: Cannot modify header information - headers already sent by (output started at /home/ACCOUNTNAME/domain/OpenPNE/webapp/lib/util/mail_send.php:60) in /home/ACCOUNTNAME/domain/OpenPNE/webapp/lib/util/util.php on line 34

「mail_send.php on line 60」で検索すると、次のサイトを見つけた。

OpenPNE　2.12.5　招待メールのエラー回避

このサイトの方によると、PHPがセーフモードの場合、mail関数に引数の制限があってそれが原因、とのことですが、私のサーバーはXSERVERを利用しているためそんなはずはないんだけどなぁ、と思いつつも同じ症状だったので試してみました。

webapp/lib/util/mail_send.php　　５３行目

if (MAIL_SET_ENVFROM){

↓

if ((MAIL_SET_ENVFROM)&&(!ini_get(”safe_mode”))) {

そして、テストすると・・・・・メール受信！！稼動しました。

有難うございました。

とはいえ、今まで動いてたものが動かなくなった点も不思議です。

サーバーの仕様が変更されたのでしょうか？

FXを勉強中、過去の円高をまとめた記事を発見。
今回はDIYというより、忘れないように覚書としてエントリー。詳しくは後ほど調べていくとしよう。

米欧の金融危機の深刻化により、外国為替市場で円が主要通貨に対して急騰する「円独歩高」が止まらない。２４日のロンドン市場で円相場は一時、１ドル＝９０円台と約１３年２カ月ぶり、ユーロに対しても一時、１ユーロ＝１１３円台の円高水準を記録し、株安を一層、推し進めかねない勢いだ。超円高は８５年と９５年と過去２回起き、輸出に頼る日本経済を翻弄（ほんろう）した。今回は、金融当局の介入も難しく、有効打を見いだせない状況だ。【清水憲司】

◇「過去とは違う」

８０年代以降の外国為替市場での円高・ドル安基調は、８５年９月２２日の「プラザ合意」が起源だ。日米英、西ドイツ（当時）、フランスの５カ国（Ｇ５）の蔵相（財務相）・中央銀行総裁がニューヨークのプラザホテルに秘密裏に集まり、ドル高是正に合意した。

当時の米国は、レーガン政権の軍事費拡張と大型減税で財政赤字が急膨張。米国債を円滑に売りさばく目的と、インフレ抑止から高金利政策を取ったが、それが実力以上のドル高を招いた。ドル高と高金利は米産業の国際競争力を低下させ、景気が低迷。企業が生産拠点を海外に移す「産業の空洞化」が加速し、雇用不安が広がった。一方、「強いドル」の恩恵で割安な日本製品などの輸入は急増した。米国は８４年、純債務国に転落し、貿易赤字も１０００億ドルの大台を突破。財政収支と貿易収支の「双子の赤字問題」が深刻化した。

議会は、米貿易赤字の３割以上を占める日本を敵視する保護主義の動きを強め、Ｇ５は米国の「双子の赤字」への対応策を迫られた。そこで出てきたのが、為替相場のドル高是正による不均衡の調整。各国当局はプラザ合意後の週明けから市場でドルを一斉に売る協調介入を開始。１ドル＝２４０円台だった円相場は１年後にＧ５の想定を超える１ドル＝１５０円台まで急騰した。

円高によるドル建て価格急上昇で日本企業の輸出は急減し、日本経済は円高不況に直面した。この苦境に、日本企業は、コスト削減と米国やアジアなど海外生産拡大で対抗。為替相場変動への体質強化を図った。政府・日銀は、景気対策や連続利下げで内需拡大を進めたが、後に不動産や株式バブルを招いた。

次に円が急騰したのは９５年春。バブル崩壊で内需が低迷する中、日本企業は再び輸出依存を強め、米国の対日貿易赤字が急増。クリントン政権は日本からの自動車輸入急増が雇用を脅かしていると主張し、日米自動車摩擦に発展した。米国が日本に貿易不均衡解消を迫る手段として、円高誘導の口先介入を繰り返したことも手伝って、円相場は４月１９日に一時１ドル＝７９円７５銭まで急騰した。円高不況の再来に日本企業は一段のコスト削減と、アジア向けなどの販売拡大で、対米輸出依存の見直しに動き出した。

自動車摩擦が収束に向かうと、米国はドル安政策を転換。米景気後退で利下げが避けられなくなり、投資家のドル資産離れが進んでドル暴落への危機感を高めたからだ。６日後の２５日の先進７カ国蔵相・中央銀行総裁会議（Ｇ７）は「ドル相場の秩序ある反転」で合意。日米欧が協調して利下げやドル買い介入を行い、超円高は収束した。米国は「強いドル」政策の下、日本やアジアなどが貿易黒字でためたドル資金を米国金融市場に還流させ、自国の経済成長を高める戦略を継続。その後、日本の景気低迷もあり、今回まで超円高は訪れなかった。

◇「困るの日本だけ」

日米欧の協調介入は００年９月のユーロ安阻止が最後。日本は０１年以降、単独で円売り・ドル買い介入を繰り返したが、円高阻止というより不良債権問題と景気悪化を背景に進むデフレスパイラルに歯止めを掛ける「円安誘導」が実態だった。米欧も、日本が不良債権抜本処理などでデフレ克服を急ぐことを条件に、この円安誘導介入を黙認した。

日本も、０４年３月を最後に為替介入を停止。円安傾向が続いたのは、欧米のファンドや投資銀行などが超低金利の日本と海外各国との大幅な金利差に着目し、円資金を高金利通貨に転換し、証券化商品などに投資する「円キャリー取引」を活発化させたからだ。

しかし、米発の金融危機が深刻化した年明け以降、為替相場は一変。米大手証券、ベア・スターンズが事実上破綻（はたん）した３月には、ドルが全面安となり、１ドル＝９５円台まで円高・ドル安が進行。Ｇ７は一時、ドル防衛の協調介入も検討した。

最近の円高局面は過去のどれとも違う。米政府主導によるものではなく、背景には、金融危機に伴う邦銀の損失が相対的に少なく「円が安全な通貨として買われている」（国際金融筋）ことがある。ファンドなどが円キャリー取引解消を急ぎ、資金返済に円を大量に買うことも拍車を掛けている。

ドルは海外からの投資資金の米国回帰もあり、円以外に対してはむしろ強含み。ユーロ急落も「これまでの過大評価の修正」（米シンクタンク）の面もあり、欧州各国が介入に動く気配はない。

市場では「企業業績の悪化など円高で困っているのは日本だけ。欧米には協調介入の理屈がない」（ＪＰモルガン・チェース銀行の佐々木融氏）との指摘もある。日本単独の円高阻止介入に乗り出すことも考えられるが、「３日で１０円も進む相場の流れを単独介入で変えるのは無理」（国際金融筋）。財務省も「かつてない市場の変動ぶりで、為替介入した場合の影響が読めない」と苦慮している。

【ことば】円キャリー取引

低金利で借りた円を、高金利の海外通貨や高利回りの金融商品で運用して収益をあげる投資手法。各国の金利差に注目してヘッジファンドが活用した。日本が不良債権問題や景気低迷で９０年代以降、ゼロ金利政策や超低金利政策を長期間続けたことで、取引が膨らんだ。ファンドなどは借り入れた円をすぐに売って外貨に替える傾向が強い。

http://headlines.yahoo.co.jp/hl?a=20081025-00000107-mai-bus_all

yumでアクセスするミラーサイトが開けないようだ。

[root@dev2 ~]# yum list updates
Loading “installonlyn” plugin
Loading “fastestmirror” plugin
Setting up repositories
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=5&arch=i386&repo=os error was
[Errno 4] IOError:
Error: Cannot find a valid baseurl for repo: base

こんな感じのエラーでとまった。

http://mirrorlist.centos.org/?release=5&arch=i386&repo=os

ここを直接みにいくと、CentOS5.2を探しているようでそれが原因なのかもしれない。（結局確認はできていないが）

ググってみるとレポジトリを変更するとよいらしく、

パッケージ管理(yum:CentOS編)

このサイトを参考に

/etc/yum.repos.d/CentOS-Base.repoを編集した

[base]
name=CentOS-$releasever - Base
baseurl=http://ftp.riken.jp/Linux/caos/centos/$releasever/os/$basearch/
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=http://ftp.riken.jp/Linux/caos/centos/RPM-GPG-KEY-CentOS-5
#gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

#released updates
[updates]
name=CentOS-$releasever - Updates
baseurl=http://ftp.riken.jp/Linux/caos/centos/$releasever/updates/$basearch/
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=http://ftp.riken.jp/Linux/caos/centos/RPM-GPG-KEY-CentOS-5
#gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

#packages used/produced in the build but not released
[addons]
name=CentOS-$releasever - Addons
baseurl=http://ftp.riken.jp/Linux/caos/centos/$releasever/addons/$basearch/
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=addons
#baseurl=http://mirror.centos.org/centos/$releasever/addons/$basearch/
gpgcheck=1
gpgkey=http://ftp.riken.jp/Linux/caos/centos/RPM-GPG-KEY-CentOS-5
#gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
baseurl=http://ftp.riken.jp/Linux/caos/centos/$releasever/extras/$basearch/
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=http://ftp.riken.jp/Linux/caos/centos/RPM-GPG-KEY-CentOS-5
#gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
baseurl=http://ftp.riken.jp/Linux/caos/centos/$releasever/centosplus/$basearch/
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centospl
us
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=1
gpgkey=http://ftp.riken.jp/Linux/caos/centos/RPM-GPG-KEY-CentOS-5
#gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

だけど、mirrorlistをコメントアウトしたのでriken決め打ち。ってところに注意。

これで上手くいくはず・・・だったけど、

[root@dev2 yum.repos.d]# yum list
Loading “installonlyn” plugin
Loading “fastestmirror” plugin
Setting up repositories
Loading mirror speeds from cached hostfile
Reading repository metadata in from local files
primary.xml.gz 100% |=========================| 91 kB 00:00
http://ftp.riken.jp/Linux/caos/centos/5/updates/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.xml.gz from updates: [Errno 256] No more mirrors to try.

こんなんなって止まってしまう。

なので、またGoogle先生の出番。先生の回答はこちらでした。

yumによるパッケージ更新時にエラーが表示される

# yum clean all
# yum update

これがいるようでした。
ふぅ。これでやっと成功！！！

現在も試行錯誤中。
なので、ブログもその過程を掲載しているためまとまりがなくなるだろうな。最後はまとめが必要になるだろう。

では、どんなことをしたいのかを一先ずまとめてみる。

■目的
Firebird1.5＋Delphiクライアントの仕組みを、Firebird2.0＋PHPのWebアプリにできないか基本的な技術確認をする

■データ量
単純な顧客管理システムであるがデータ量が結構ある（自分の経験の中では）
顧客数：50,000件以上
販売データ：200,000件以上
販売明細データ：400,000件以上
対応データ：400,000件以上
画像データ：未確認（DBにつっこんである）

がサクッと動く事。まぁサクッと動くかどうかは環境が出来てからの話しだな。

■開発サーバースペック
詳細調べてないのでのちほど追記。
分かってるのはメモリが1GBってことくらいかな。
本番で導入となったらCore2Duoのメモリ2GB、RHEL5というマシンになる。

とゆー感じなので、とにもかくにも、Firebird2.0をPHPから扱えるように頑張ってみよう。

PHP5からの実装された（？）データベース接続のコンポーネントである、PDOで、LIMIT句のプリペアードステートメントに関するおかしな現象を見つけた。

不具合なのかサーバーの環境なのか、自分のスキル不足（←この可能性大）なのかわからいが、その例を覚書。

自分のXREA+Plusでの環境
・PHP5.2.5
・MySQL5.1.22
上で、

$rs = $myDB->prepare(’SELECT * FROM tableA WHERE id = ? group by id order by id LIMIT ? ,10′);
$rs->execute(array($_GET['id'],$page));

というPDOを使った処理を行おうとしたが、どうもLIMIT句の部分がうまくいかない。
limit句の？を直接数字にしてみると動作しているので、プリペアードステートメントに関する不具合？かとも思った。

ググってみると
http://kandk.cafe.coocan.jp/blog/jeans/index.php?itemid=617

似たような人がいたので、やはりそうなのかと。

とりあえず、

$rs = $myDB->prepare(
‘SELECT * FROM tableA WHERE id = ? group by id order by id LIMIT ‘.$page.’ ,10′
);
$rs->execute(array($_GET['id']));

こんな感じで、LIMIT句のところだけはプリペアードステートメントを止める形で実装したら動作した。

ちなみに、ローカルの環境では、この問題は起こってない。
どういうバージョンで起きるのだろうなぁ。

[2009.1.21フォローエントリー]

追記：PDOでLIMIT句のプリペアードステートメントに関する不具合？