問題タブ [prepared-statement]

クエリで名前付きパラメーターを使用して、マップのようなデータ構造のフィールドを照合しています。データ構造には、フィールド、または別のマップのようなデータ構造を含めることができます。このネストされた構造は、反復可能であり、うんざりです。

さらにネストされたルックアップを示すために解析できる XPath のような言語を使用して、クエリのパラメーターに名前を付けたいと思います。

問題は、名前付きパラメーターの宣言で有効な文字は何ですか?

Android の SQLite で準備済みステートメントを使用するにはどうすればよいですか?

データベーステーブルから削除したい主キー値のセットを生成するコードがあります。

そして、PreparedStatementを使用して同等のものを実行したいと思います

どのようにアイデアはありますか？

mysqli_stmt::bind_paramPHP5 で使用するブール値のバインドに問題があります。

SQL クエリは次のとおりです。

ここで、'read' は 0 または 1 の tinyint です。したがって、bind_param にリストするタイプは次のとおりです。

「sdsb」と「sdss」も試しましたが、何も機能していないようで、常に次のメッセージが表示されます。

警告: mysqli_stmt::bind_param(): 変数の数が、準備されたステートメントのパラメーターの数と一致しません

ステートメントの読み取りフィールドを削除すると、すべて正常に機能します。私はこれでアイデアを使い果たしました。確かにbind_paramはブール値で動作しますか?

ADO.Net 経由で SQL Server 2005 バックエンドと通信する VB.Net フロント エンドを備えた .Net Web システムがあります。基本的に、私がやりたいことはこれです：

並べ替え順序がクエリ文字列などを介して渡される場所。このコードは、「'@SortOrder' 付近の構文が正しくありません。ステートメントを準備できませんでした。」をスローします。

これは可能ですか、それとも私が見ていない本当にばかげた構文エラーがありますか?

(そして、はい、クライアントは .net 2.0 しか実行していないため、残念ながら LINQ ベースのソリューションは機能しません。

皆さんありがとう！

更新/応答:

まあ、それは私が思ったことです。皆さん、健全性チェックをありがとう。(一部のコンテキストでは、コマンド文字列は現在動的に構築されていますが、システムをより準備されたステートメントの方向に動かしています。これは、私が可能だとは知らなかったエッジケースの 1 つでした。

再度、感謝します！

IN パラメーターを LIKE ステートメント内で機能させるために何時間も戦っています。私は CachedRowSet を使用していますが、これは PreparedStatement と同じ規則に従う必要があることを理解しています。
基本的なクエリは次のとおりです。

someString は既知の ID ですが、データベース (ちなみに PostgreSQL) エントリには不明な 2 文字のサフィックスがあります。

最小限のデータベースを使用する PHP 駆動の Web サイトを再設計しています。元のバージョンでは、"pseudo-prepared-statements" (クォートとパラメーターの置換を行う PHP 関数) を使用して、インジェクション攻撃を防ぎ、データベース ロジックをページ ロジックから分離していました。

これらのアドホック関数を、PDO と実際のプリペアード ステートメントを使用するオブジェクトに置き換えるのは当然のことのように思えましたが、それらについて読んだ後では、よくわかりません。PDO は依然として素晴らしいアイデアのように思えますが、プリペアド ステートメントの主なセールス ポイントの 1 つは、それらを再利用できることです。これが私のセットアップです：

• ステートメントはすべて自明です。ほとんどは の形式SELECT foo,bar FROM baz WHERE quux = ? ORDER BY bar LIMIT 1です。多くの中で最も複雑なステートメントは、s で結合された 3 つの selectUNION ALLです。
• 各ページ ヒットは、多くても1 つのステートメントを実行し、1 回だけ実行します。
• 私はホストされた環境にいるため、個人的に「ストレステスト」を行ってサーバーを非難することに不安を感じています.

プリペアド ステートメントを使用すると、データベースへの往復回数が少なくとも 2 倍になることを考えると、それらを避けたほうがよいでしょうか? PDO::MYSQL_ATTR_DIRECT_QUERYパラメータ化とインジェクション防御の利点を維持しながら、複数のデータベーストリップのオーバーヘッドを回避するために使用できますか? それとも、準備されたステートメント API で使用されるバイナリ呼び出しは、準備されていないクエリを実行する場合と比較して、心配する必要がないほど十分に機能しますか?

編集：

皆さん、良いアドバイスをありがとう。これは、複数の回答を「承認済み」としてマークできたらいいのにと思います。さまざまな視点がたくさんあります。しかし、最終的には、私はリックに当然のことをしなければなりません... 彼の答えがなければ、私は幸せに立ち去り、みんなのアドバイスに従ったとしても、完全に間違ったことをしたでしょう. :-)

エミュレートされた準備済みステートメントです。

私が取り組んでいるプロジェクトで、さらに別のばかげたサニタイズされていないSQLインジェクションの欠陥に（偶然に）偶然出くわしました...そして私はそれにとてもうんざりしています。
このような悪いSQLステートメントを排除し、可能な限り準備済みステートメントを強制する方法について何かアドバイスはありますか? 今、私は次のような解決策を好むでしょう

��かし、これはありそうもないので、これらのものを見つけるための静的コード分析ツールなどはありますか (一定の信頼性まで)? または他に何かお勧めはありますか？
編集：ソフトスキルのアプローチ「それらを使用しないでください。（通常）より良い方法があります」は、過去にはあまりうまく機能していないようでした. したがって、そもそもそのようなクエリを防止するものを本当に好むでしょう。既存のコードを故意に壊すのではなく、将来のプロジェクトのために、「そのようなクエリはありません」という解決策があります;-)

クエリから結果を取得してページに表示するために、次のコードを試していtes.phpます。

db.inc.php

tes.php

エラー メッセージは表示されませんが、結果は表示されません。空白のページです。

私は何を間違えましたか？

Java の他のどこでも、インデックスを持つものはすべて 0 から始まります。ここに変更の理由はありますか、それとも単に設計が悪いのでしょうか?