好きな和訳タイトルを教えてください

で実行すると実行は正しくされているようですが
クエリは結果を返却しませんでした。
というエラーメッセージがでます
selectとinsert,delete,create
を共通に実行できるメソッドはあるでしょうか?

質問者からの補足コメント

  • private ResultSet dtbs(Connection cnnctn,String sql)
    {
    ResultSet rs=null;
    try
    {
    Statement stmt=cnnctn.createStatement();
    if(stmt.execute(sql))rs=stmt.getResultSet();
    }
    catch(SQLException e)
    {
    System.err.println(e);
    }
    return rs;
    }


    stmt.execute(sql)が正解でした
    これ一本でいけることがわかりました

    No.3の回答に寄せられた補足コメントです。 補足日時:2024/08/22 07:22

A 回答 (4件)

Statement, PreparedStatement, CallableStatement で用意されている


execute(String), execute()はステートメントの種類によってアプローチが
違うだけで、やってることはすべて同じですよ。

なので、どのように実行されるのかとどういう結果が得られるのか、という説明は文章の言い回しの違いはあれど、内容は一緒です。

https://docs.oracle.com/javase/jp/21/docs/api/ja …
https://docs.oracle.com/javase/jp/21/docs/api/ja …
CallableStatement::execute()は、PreparedStatement::execute()からの継承。

だから補足のコードでもgetResultSet()をわざわざ呼んでますよね。
まぁ、テストコードを書いたり、まずは結果セットの取得可否をboolを受けた後に何かを判断する必要がある、というシーンではexecute(), getResultSet()を使ってもいいんですが、特別な理由がないのにわざわざ使う必要がありません。
execute(), getResultSet()を利用するのが基準ではなく、特別な理由がある場合に限ってはそういう書き方をする、がベターです。
例えばローコードツールみたいなものを作っていたとして、ユーザーが任意で指定したSQLを実行するアクションがあった時、ツール側としては結果をどのように受け取りたいかをユーザーに指示してもらわないとそのSQLが何を求めたいのかわからない、とかそういうシチュエーションとかですかね。
内部実装として求める結果が当然定まっている時に利用するものではありません。
また、補足のコードでは、その実行が横行すると、前回私が指摘したような懸念点が顕在化します。


Statementを利用する時は、パラメーターが必要ないSQLを発行する時、
PreparedStatementを利用する時は、パラメーターが必要なSQLを発行する時、
CallableStatementを利用する時は、ストアドプロシージャ―を発行する時
です。

しかし、Statementを利用することは特別な理由がない限り避けた方がよいです。
例えばSQL文の文字列を動的に組み立ててSQLを発行する時にStatementは利用できます。
しかし、ある動的に変化する条件の値などをSQL文の文字列にそのまま組み立てると、SQLインジェクションの温床になります。
そういった問題もある中で、プリペアドステートメントというが概念があります。

そういうことがなければ別に使ってもいいんですが、わざわざパラメーターがあるか/ないかで利用するステートメントの種類を変える必然性がありません。
ストアドプロシージャの実行でないなら、それこそこれはPreparedStatementで一本化していいのです。
パラメーターがなければ指定しなければいいだけですからね。
脆弱性を生み出してしまうかもしれないアプローチを許容する必要性がありません。
このことから、よほど特別な理由がない限り、Connection::createStatement()を利用するシーンは出てこないと思います。

execute()の利用意義はともかくとして、例えば補足と前回回答のお礼にあるコードをベースにすると、下記でいいのです。
private ResultSet dtbs(Connection cnnctn,String sql)
{
ResultSet rs = null;
try
{
PreparedStatement ps = cnnctn.prepareStatement(sql);
if(ps.execute())rs=ps.getResultSet();
}
catch(SQLException e)
{
System.err.println(e);
}
return rs;
}

SQLを実行したい時はConnection::prepareStatement()を利用すればいいし、ストアドプロシージャを実行したい時はConnection::prepareCall()を利用すればいいのです。
    • good
    • 0
この回答へのお礼

ありがとうございます
ご提案のコードに差し替えて使っています

お礼日時:2024/08/22 17:08

> resultsetを返すメソッドで使いたいのでexecuteだと


> getresultsetを使わないといけないので手間が増えます

ですよね。
ですからそもそもResultSetを求めるのが明白ならexecuteQuery()を利用すべきで、
そうでない場合はexecuteUpdate()を利用すべきです。

なんだか分からないけどとりあえず実行する、という発想なら
execute()を実行することと、やってることが変わらないんです。
目的が違うのだから、命令も異なるのは自然なことです。

品質を悪化させるから、目的の異なる命令アプローチを一本化する意義がありません。
例えばINSERTを発行しただけなのに、自分が何しているかもよく分かっておらず、
でも結果はResultSetオブジェクトを受け取るから、それを何か操作できるようだ、
という誤解を生み、誤ったオブジェクト操作を誘発させます。

独自のラッパークラスでも用意してそこで判断して、独自の結果クラスでも返却するなら別ですが。

まぁ結果的にどうしたいかはご自由にどうぞですが、個人的にはその一本化する方法論をおすすめすることはありません。
この回答への補足あり
    • good
    • 0
この回答へのお礼

private void dtbsx(Connection cnnctn,String sql)
{
ResultSet rs = null;
try
{
PreparedStatement ps = cnnctn.prepareStatement(sql);
ps.executeUpdate();
}
catch(SQLException e)
{
System.err.println(e);
}
}
ご意見を参考に
結局、妥協してdtbsとdtbsxの2メソッドでやることにしました
selectのときdtbsを使いinsert等々のときdtbsxを使うことにしました

お礼日時:2024/08/21 18:43

> 使い分ける面倒を回避するためには


> エラーがでて気持ち悪いけれど実害がないのでexecuteQuery一本で行く
> しかない様ですね

そのような考えであれば、execute()でも実行はできます。
https://docs.oracle.com/javase/jp/8/docs/api/jav …

ただし、自分が求めているものが明白な時に利用するものではありません。
戻り値の結果となる可能性が混在して考えられる場合には利用するかもしれませんが、条件が揃わないとそのようなことは起こりません。

execute()を利用する場合は、自分で求めることを把握した上で二度手間の命令呼び出しが必要になります。
(レコードセットや影響件数を別個で求める必要がある)

本来、求めることが明白なのだから、そこにマッチする命令を利用すべきです。
    • good
    • 0
この回答へのお礼

private ResultSet dtbs(Connection cnnctn,String sql)
{
ResultSet rs = null;
try
{
PreparedStatement ps = cnnctn.prepareStatement(sql);
rs = ps.executeQuery();
}
catch(SQLException e)
{
System.err.println(e);
}
return rs;
}

resultsetを返すメソッドで使いたいのでexecuteだと
getresultsetを使わないといけないので手間が増えます

お礼日時:2024/08/21 16:42

executeUpdateは影響レコード件数を得る命令であり、


executeQueryは抽出されたレコードセットを得る命令になります。

共通化する必要がなく、得たい情報がそれぞれで異なるため、
DMLに依存しないで実行するための命令というものは存在しません。
    • good
    • 0
この回答へのお礼

回答ありがとうございます
使い分ける面倒を回避するためには
エラーがでて気持ち悪いけれど実害がないのでexecuteQuery一本で行くしかない様ですね

お礼日時:2024/08/21 15:48

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています


おすすめ情報

このQ&Aを見た人がよく見るQ&A