Обсуждение: About server side prepare
Hiroshi Inoue, > >Please check and try the new *Server side prepare* DSN option. >Note that the option is effective only for 7.3 severs. > >regards, >Hiroshi Inoue I'm using 7.3 server. The SQLRowCount after server side prepared insert returns row count -1. But the row was actually inserted successfully! regards! Han zhouhanok@vip.sina.com 2002-12-20
Han wrote:
>
> Hiroshi Inoue,
>
> >
> >Please check and try the new *Server side prepare* DSN option.
> >Note that the option is effective only for 7.3 severs.
> >
> >regards,
> >Hiroshi Inoue
>
> I'm using 7.3 server.
> The SQLRowCount after server side prepared insert returns row count -1. But the row was actually inserted
successfully!
Good catch. Hmm this may be a serious problem because
there's no way to know the row count when we use EXECUTE
statements.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
Hiroshi Inoue,
>> Another question is that why prepare every time when calling SQLExecute?
>
>Do you call other ODBC APIs between the first SQLExcute and the
>second one ?
>
>regards,
>Hiroshi Inoue
Oh yes, I called SQLFreeStmt(stmt, SQL_CLOSE) between SQLExecutes.
Han
zhouhanok@vip.sina.com
2002-12-20
Han wrote:
>
> Hiroshi Inoue,
>
> >> Another question is that why prepare every time when calling SQLExecute?
> >
> >Do you call other ODBC APIs between the first SQLExcute and the
> >second one ?
> >
> >regards,
> >Hiroshi Inoue
>
> Oh yes, I called SQLFreeStmt(stmt, SQL_CLOSE) between SQLExecutes.
OK please try the latest cvs.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Good catch. Hmm this may be a serious problem because
> there's no way to know the row count when we use EXECUTE
> statements.
I wonder if EXECUTE could/should be made to return the appropriate
command status string for the executed statement, instead of "EXECUTE".
regards, tom lane
Tom Lane wrote: > Hiroshi Inoue <Inoue@tpf.co.jp> writes: > > Good catch. Hmm this may be a serious problem because > > there's no way to know the row count when we use EXECUTE > > statements. > > I wonder if EXECUTE could/should be made to return the appropriate > command status string for the executed statement, instead of "EXECUTE". I think it should return "EXECUTE" with the counts from the commands. Does that make sense? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I think it should return "EXECUTE" with the counts from the commands.
> Does that make sense?
No. It would break client libraries, which only expect command tags
INSERT, UPDATE, DELETE to be followed by counts. Also, INSERT has two
numbers associated with it, the others only one; if we allow both those
cases for EXECUTE then life gets even worse for the client library.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I think it should return "EXECUTE" with the counts from the commands. > > Does that make sense? > > No. It would break client libraries, which only expect command tags > INSERT, UPDATE, DELETE to be followed by counts. Also, INSERT has two > numbers associated with it, the others only one; if we allow both those > cases for EXECUTE then life gets even worse for the client library. It is easy to determine what tag to return? Remember the discussion on rules and that only the original tag should be returned. Is there always one obvious tag to an execute? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> It is easy to determine what tag to return? Remember the discussion on
> rules and that only the original tag should be returned. Is there
> always one obvious tag to an execute?
I would think we'd do it via the rule that we return the same thing
you'd get if you directly issued the query that appears as the body
of the PREPARE command. All the special cases for rules and so on
seem to apply the same way if you do that.
regards, tom lane
"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:
> On Fri, Dec 20, 2002 at 12:56:55PM -0500, Tom Lane wrote:
>> No. It would break client libraries, which only expect command tags
>> INSERT, UPDATE, DELETE to be followed by counts.
> And MOVE, right?
Mph ... PQcmdTuples only knows about INSERT/UPDATE/DELETE. Looks like
we already made this mistake once before ;-).
regards, tom lane
Tom Lane wrote:
>
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Good catch. Hmm this may be a serious problem because
> > there's no way to know the row count when we use EXECUTE
> > statements.
>
> I wonder if EXECUTE could/should be made to return the appropriate
> command status string for the executed statement, instead of "EXECUTE".
Maybe it's preferable.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/