[JDBC] Fastpath error on solaris 2.8 pgsql 7.1.3

2001-08-27 Thread T . R . Missner
Anyone seen this error before? It doesn't happen every time I insert a blob so I assume the code is correct. Only happens occasionaly. I have no idea how to troubleshoot this problem. Any help would be appreciated. FastPath call returned ERROR: lo_write: invalid large obj descriptor (0) I

Re: [JDBC] JDBC changes for 7.2 - wish list item

2001-08-27 Thread Rene Pijlman
On Mon, 27 Aug 2001 08:48:52 +1000 (EST), you wrote: It's been mentioned before, but a set of error numbers for database errors would make trapping exceptions and dealing with them gracefully a LOT simpler. I have java code that runs against Oracle, Informix, PostgreSQL, MS SQL Server and

RE: [JDBC] Fastpath error on solaris 2.8 pgsql 7.1.3

2001-08-27 Thread chris markiewicz
I have exactly the same problem...it happens randomly, it seems. maybe 5% of the time. also happens on selects (lo_read though). the only advice that i've seen on the topic is to make sure that autocommit is set to false, which i've done, but i still see the problem. unfortunately, my next

Re: [JDBC] Re: [BUGS] Bug #428: Another security issue with the JDBC driver.

2001-08-27 Thread Barry Lind
No this is not the way to do this. Elsewhere when the driver has different functionality/requirements for JDBC1 vs JDBC2 this is impelmented via subclassing (see the jdbc1 and jdbc2 packages). That pattern should be followed here, not the kludgy fake ifdef support provided by configure.

[JDBC] Re: Proposal to fix Statement.executeBatch()

2001-08-27 Thread Barry Lind
Rene, I see your statements below as incorrect: The intended behaviour is to send a set of update/insert/delete/DDL statements in one round trip to the database. Unfortunately, this optional JDBC feature cannot be implemented correctly with PostgreSQL, since the backend only returns the

Re: [JDBC] Fastpath error on solaris 2.8 pgsql 7.1.3

2001-08-27 Thread Tom Lane
[EMAIL PROTECTED] writes: FastPath call returned ERROR: lo_write: invalid large obj descriptor (0) Usually this indicates that you didn't have the lo_open ... lo_write ... lo_close sequence wrapped in a transaction block (BEGIN/COMMIT SQL commands). Since it's erratic for you, I'd bet that

Re: [JDBC] Re: Proposal to fix Statement.executeBatch()

2001-08-27 Thread Rene Pijlman
On Mon, 27 Aug 2001 11:07:55 -0700, you wrote: [executeBatch() implemented as one round trip] Here is how I would suggest this be done in a way that is spec compliant (Note: that I haven't looked at the patch you submited yet, so forgive me if you have already done it this way, but based on

[JDBC] Re: [PATCHES] Attempt to clean up ExecSql() in JDBC

2001-08-27 Thread Barry Lind
I looked at the patch and it looks fine. As for what fqp and hfr stand for I don't have a clue. I was looking through the fe/be protocol documentation and think I might have a clue about what they are being used for. thanks, --Barry Anders Bengtsson wrote: Hi, Attached is my attempt to

Re: [JDBC] Re: Proposal to fix Statement.executeBatch()

2001-08-27 Thread Barry Lind
What exactly is the behaviour of the backend in that scenario? Does it commit every separate SQL statement in the semicolon-separated list, or does it commit the list as a whole? Does it abort processing the statement list when an error occurs in one statement? And if it continues, does