バイナリファイルを開いて「文字化け」とはかわいいね。

>>55
functionでおま。
問題は解決。
データベースのデータがページに出力されたのをみた瞬間、
ニヤリと笑ってしまった。ああ、プログラムの喜びよ（おおげさ）

できるみたい。
http://www.softagency.co.jp/mysql/Win/win.html
とりあえず試してみます。

簡単にできた

PHP側の問題としては、標準的なSQL要求に対してのグローバルな
インタフェースを用意できていないのが問題な気がする。
一度決めたDBを乗り換えようとした場合、ムチャクチャ大変でそ？

この辺、どーにかならんのかね…

あと、MySQLってトランザクションが無い時点でいきなり候補から落ちない？
そもそも商用に使っていいんだっけ？

>>61
PHP4 には一応抽象化 DB クラスがあったりしますね。
で、 PHP4 で増えたこのあたりの機能のことを見ようと 「PHP4徹底攻略」を
買ってきたんだけど、 DB 回りのサンプルは PHP3 対応の旧版とほとんど
かわってねーんでやんの。
セッション機能なんかもさらっと触れられてるだけだし。

巻末の役に立たないリファレンスなんかいらないからそのあたり詳しく
書いて欲しかった。

>>63
あの本はダメだよねえ。というか PHP ユーザー会で Pear に取り組もうと
いう人が広川さん以外にいない時点で、かなり終わっているね。
最近はろくな活動もしていないみたいだし。

いつまでも『PHP + PostgreSQL による高機能 Web の構築』じゃないだろうに。

・どうやったら生産性を高めることができるか
　・どうやったら同じコードを何度も書かずにすむか
　・どうやったら同じバグに遭遇しないですむか
・どうやったら設計が簡単になるか
　・どうやったら設計情報を抜け漏れなく記述できるか
　・どうやったら設計情報を共有できるか
・どうやったら実装が簡単になるか
　・どうやったらビジネスロジック層と永続化層をきれいに分けることができるか
　・どうやったらオブジェクトの永続化が容易になるか
といった課題を解決していかないと、小規模案件の書き捨て用言語以上の存在には
ならないだろうね。で、最初のはクラスを使うことでかなり解決できるし、
二番目のは UML（+ Web 拡張）かな？という気もするし最後のは既存の方法論が
使えるし、十分クリアできるじゃーんとか思うんだけどなぁ・・・。

>>63-64
言いだしっぺの法則の適用を望みます。
それを本気でやったらPHP界の英雄になれますよ。それだけでは食ってけないでしょうけど (苦笑

>>65
うひゃあ！うっかり余計なことを言うもんじゃないなあ。
まあ何か出てきたらこの板にて書きますわ。

ちなみに PHP ユーザー会は日本語化についてかなり貢献していることにも
触れておかないと片手落ちだね（もともと日本語化のメンバーが中心だしなあ）。
だからクラスがどうのこうのよりも日本語化にしか関心がないという推測も
できるかもね。

PEARのDB.php(pgsql.php)使ってみたけど、ちょい使いづらいぞ。

あれ・・・書き込まれない。リトライ。

>>67
なんのなんの、あれの原型になっていると思われる DBTools.h++ に比べれば
まだまだ素直でしょう。DBTools.h++ に興味があったら
http://www.roguewave.com/support/docs/dbtug/index.cfm
へどうぞ。

冗談はともかく、慣れの問題もあると思うよ。connect->exec->result->close という
手順に慣れていると fetch だのなんだのいったお約束は邪魔に感じるとは思う。
その印象は正しいと思う。

ただ、この手のクラスライブラリは
・どのデータベースにアクセスするにも同一の手順を使える
　-> 覚えることは一つでよい
・少なくとも Pear の中のロジックについては信頼して使える。
　つまりデバッグすべき範囲を限定できる
という点に大きなメリットがあるから、そのアプリケーションを PostgreSQL
以外の RDBMS に移植するとか、アプリケーションごとに異なる RDBMS を使う
必要があるといった場合にならないとメリットを感じられないかもしれない。

言い換えれば、RDBMS の実装を一つに固定してしまうなら Pear の DB クラスは
それほど威力を持たないということ。自分でアクセスクラスを書いた方が多分
便利だろうね。

遅いって、classとかで包容しようとするならそれは仕様つーか命題つーか。
ブラックボックスアプリがでかくなるのは当然でそれはシステムで補っていただきませう。

今書いてるモノだと、こいつは絶対エラーにならんから処理省いちゃえ的に
書くこと多いんであとで苦労することが多いんだよね。
classがそれを助けてくれるのなら大歓迎。
次のシステムで実験させて貰います。

> ・Selectする手段がquery(), simpleQuery(), execute()と複数あり、迷ってしますう。

simpleQuery と query はともに直ちに実行可能な SQL 文を渡して処理するメソッド。
ただ、前者の場合には戻り値が pg_result で利用可能な結果識別子なのに対して、
後者は DB_result 型のオブジェクトが返るところが違うようだね。

execute() は prepare() とセットで実行されることが前提。で、prepare() に渡す
SQL 文には、? と & という特別なバインド変数を定義できて、前者の場合には
第二引数で渡された値（配列中の値）が、後者の場合には渡された値と同じ名前を
もつファイルの中身を SQL 文の中に結合することができるみたい。

> ・遅い（単純なページで、ページあたり+20～+30msかかる）

>>71 さんのおっしゃる通りだと思う。
あとは Zend Cache 使うとか・・・。

あぁぁー、すごい勘違いをしてた。
インスタンス変数って、プライベートだと思っていたら、パブリック
だったんですね。
道理で、アクセッサメソッドが無いわけだ。

それから、各メソッドの説明どうもです > 電動ナナシさん
prepare() & execute()の機能には、ビックリです。
>prepare():
>Prepares a query for multiple execution with execute(). With
>PostgreSQL, this is emulated.
じゃ分からんぞ(w

恥ずかしい質問なのでsage。
$ret = $db->simpleQuery("set client_encoding to 'EUC_JP'");
if ($ret != DB_OK) {
  exit;
}
とやったところ、エラーが発生してもexitしない。
これは、エラーが発生したときに、$retに文字列が入っていて、
比較するときに文字列->数値という変換がなされ、
if (0 != 0)
という比較になるので、このifブロックには絶対に入らない。
正しくは、
if ($ret !== DB_OK)
とする必要がある。

・・・という解釈は正しいですか？

さらに疑問が。

(1)のエラー判定は、こうするしかないのでしょうか？
ほかに判断の方法はありますか？

require("DB.php");

$db = DB::connect("pgsql://localhost/testdb");
if (DB::isError($db)) {
  exit;
}

$sql = "select emp_code, emp_name from emp";
$res = $db->query($sql);
if (get_class($res) != "db_result") {    // (1)
  exit;
}
//echo $db->numrows[$res->result] . "<br>\n";
echo "<table>\n";
while ($row = $res->fetchRow(DB_FETCHMODE_ASSOC)) {
&nbsp;&nbsp;echo "<tr><td>$row[role_name]</td><td>$row[emp_name]</td></tr>\n";
}
echo "</table>\n";

というか、ソースなんぞ見なくても、サクサクプログラミングできるのが
PEARの目標だと思うのだけれど・・・。

>>81
そうなんだよね。まだまだ発展途上。ドキュメントもないし。
そのうちクラス図を作って公開する予定。

>>80
>>79 は合ってる。それで正解。というか DB に限らず PEAR 共通の例外機構のような
ものを作りたいみたいなんだよね。で、
・メソッド実行して、成功なら普通のオブジェクトを、失敗なら PEAR_error 型の
　オブジェクトを返す
・オブジェクトについて isError($returnedObject) で成功・失敗を判定
という風にしたいような感じなんだなあ。

MySQL と OCI8 は確かにエラーが起きると raiseError() して DB_error 型
（こいつは PEAR_error を継承している）を生成して返すようになっているけど、
DB_pgsql.php はそうなっていないという点が問題みたい。

広川さん（DB_pgsql の開発者）に連絡するか、自分でパッチ送って submit すると
喜ばれるんじゃない？自分も暇が出来たらやってみよう。

あー、でも PostgreSQL ってエラーコードがない（errorMessage() で取得する
しかない）んだよね。それで実装されてないって可能性が大きいかも。

DB_pgsql.php の errorNative() のコメントを見てそう思った。

>>86
>ただ、アクセス方法やエラーハンドリングを標準化する意義は十分あると
>思うなあ。JDBC に批判的なように、近藤さんはこの手の抽象化ライブラリ
>全般に不信感があるのかもしれない。

それは、よーくわかります。

>コードの信頼性は、チャレンジャー（人柱）の犠牲によって獲得していく
>しかないだろうね。すると人柱が一番多いのはどれだ？という話になると
>思う。今のところ PHPLib > Pear >> その他 という感じかなあ。

私はPHP4.0.4から入ったので、PHPLibは使ったことないのですが、
それに慣れて、しかも発言力ある人たちが、「Pearは不安定だ、
未完成だ、使えないぞー」と声高に（というのは私が受け取った
印象ですが）言うのは、やめて欲しいなー、という感じですね。

PearはCVSで追っかけることが出来るようになったんですが、
なにしろ、時間が無い・・・。来週末までに、今作っているシステムを
完成しないといけないんです（グチ）。

誰か最新版を追っかけて、評価する人いないかなー。
# 結局、他人を頼るのかいっ! (w

新しいマニュアルをダウンロードしたら、PEARの章が出来てました。
忙しい人の為に、目次を引用。

V PEAR: the PHP Extension and Application Repository
23 章 PEARについて
- PEARとは?

24 章 PEAR コーディング標準
- インデント
- 制御構造
- 関数のコール
- 関数の定義
- コメント
- コードの読み込み
- PHPコードのタグ
- ヘッダのコメント部
- CVS タグ
- URLの例
- 定数の名前

LXXXIII PEAR リファレンスマニュアル
- PEAR PEAR基底クラス
- PEAR_Error PEARエラー処理機能の基底クラス

やはり、PEARのエラーハンドリングの思想は、エラーオブジェクトを
返す、というので正解でした。

>>93 ありがとうございます。
おっしゃる通り、nobody自体のアカウントが作成してありませんでした。
目標とする結果はブラウザ上に現れませんでしたが、今回は間違いなくDB
への接続は出来ているようです。
私のスクリプトが間違っていると思われ、ブラウザ上には何もエラーメッセ
ージは出ませんが、画面は真っ白でした。

今度こそ、ゆっくりスクリプトの方に挑戦してみます。

また判らないことありましたらお伺いさせていただきます。

只今スクリプトの間違いを訂正して、ようやくDBからのデータ出力が出来ました。
まだ勉強を始めたばかりのため、複雑なSQL文やPHPのスクリプトは書けませんが、
取り敢えずブラウザ上にデータが表示されたことには感動しました。