Calender
Sun Mon Tue Wed Thu Fri Sat
     12
3456789
10111213141516
17181920212223
24252627282930
<< November 2019 >>
広告
SEARCH

SELECTED ENTRIES
RECENT COMMENTS
RECENT TRACKBACK
CATEGORIES
ARCHIVES
LINKS
PROFILE
OTHERS
SKYPE
PC: skype.jojo.jp
chat
iPad: iphone.jojo.jp
chat call
THANKS



本日:
昨日:
多言語
広告
 ▼▲ 作業日報 ▼△
    What's under the hood?
<< 奈良のマスコットキャラ、ヌル坊? | main | 桜、愛知県江南市役所前 >>
PHPのPDOによるSQLServer接続、日付型の変換NG
04/01追加:
 後日、php.ini の「mssql.datetimeconvert」項目 は「PDO:mssql:」に対するものではなく「SQLServer関数」に対するものだったということに気づきました。PDO:mssqlでの日付型の無変換設定はできないようです

 PDO経由でSQLServerの日付型のデータを持ってくると「03 4 2007 12:00AM」という形で入ります。通常、php.iniか、ini_set()で変更できるはずの「mssql.datetimeconvert値」を"0"に設定しても「2007-03-04 12:00:00」の形にになりません
mssql.datetimeconvert = "0" (マニュアル)
mssql.datetimeconvert = Off (iniファイルコメント)
mssql.datetimeconvert = false (サイトへの書込)

 設定ファイルによる変更、ini_set()による変更、全部試したのですが、日付は"02 4 2007 12:00AM"の形のまま、、

 これも少し前のPHPのバグとして報告されている現象のようなので、FIXしたっぽいような形で終わっているのですが、、環境依存なのかもしれません。。

Bug #20920 mssql.datetimeconvert=0 doesn't work for smalldatetime
Bug #12655 date-format problem


めんどうだけど自力でやるかな・・・

 代替策として『Microsoft SQL Server 関数』を利用するとdatetimeconvert の値が反映されるようになりました。

・「Microsoft SQL Server 関数」サンプル
(0)日付出力設定
ini_set('mssql.datetimeconvert','0');
(1)接続
$msdb = mssql_connect('127.0.0.1','user','pass');
(2)DBの選択
mssql_select_db("hogehoge",$msdb);
(3)SQLの実行
$stmt1 = mssql_query( 'select * from aaa' , $msdb );
(4)レコードの取り出し //fetch(PDO::FETCH_NUM )相当
while ($row = mssql_fetch_row( $stmt1 ) ){
 echo $row[0];
}
(5)レコードセットの開放
mssql_free_result(stmt1);
(6)DBのクローズ(自動的にもクローズされます)
mssql_close($msdb);


嵌ってしまったSQLiteの日付型、比較演算子
sqlite で、
select * from hogehoge where [日付] = '2008-03-13';はダメ
select * from hogehoge where date([日付]) = '2008-03-13';....OK
select * from hogehoge where date([日付]) = '2008-3-13';もダメ
select * from hogehoge where date([日付]) = date('2008-3-13');もダメ
select date('2008-3-13') .... null
日付は正確に YYYY-MM-DD HH:NN:SS 形式
SELECT date("2008-01-01","+3days");
で3日後を返す
| 開発関連 | 12:09 | comments(0) | trackbacks(0) |









http://blog.jojo.jp/trackback/862887