Re: The bugs are getting harder to find...

-----Original Message-----
From: Donald Fraser [mailto:demolish(at)cwgsy(dot)net]
Sent: 20 December 2002 16:58
To: pgadmin-support(at)postgresql(dot)org
Subject: Re: [pgadmin-support] The bugs are getting harder to
find...


Hi Dave,
that fixed one problem and created a minor one when you don't
have any parameters - you get a single quote mark ('). Minor minor bug
and I can live with that.

Aww nuts. Sorry, fixed now (I can't live with it :-) ). The fix affects
only pgSchema.dll, so you can just update that.

I am using the software every day now and I envisage I will
continue to do so for the next month. Hence I am really happy that it's
pretty stable now.

Cool, glad you're finding it useful.

I have discovered one major bug - a crash (memory could not be
read error) when executing a SQL query on a view. Unfortunately it's not
easy to reproduce for you without sending you a lot of table
information, views, rules, PL/SQL functions, trigger functions etc. The
basic query is very simple - an INSERT INTO view statement. The view
obviously has rules on it and it inserts data into more than one table.
I'm guessing that may be the return result of the query is something
that the MDAC driver is not expecting for an INSERT INTO query and
therefore crashes!

Sounds like it for 2 reasons. Firstly, pgAdmin relies on MDAC to tell it
if there are results to display, or if it was a non-query (MDAC has no
concept of scalar queries). Secondly, one of the nice things about
Visual Basic is that you can always blame invalid memory locations etc.
on VB itself or one of the libraries in use, because VB has no memory
access to speak of. You cannot create invalid pointers as you can in
C/C++.

Data is actually entering the database, therefore the query is
arriving at the server, executing and completing. Hence why I think it
is the return result that is causing the crash. When I run the query
from psql on the server I get the following returned.
insert_persnl_user
--------------------
(0 rows)
So I am getting a column returned from the last function
(insert_persnl_user) that is run, which is weird as this is not the last
statement - a normal INSERT INTO is the last statement to be run in one
of the rules.

Anyway don't worry about it as I can ssh into the server and
issue SQL commands with psql to test stuff when the above is going to
cause a problem.

I might have another look at it and see if I can reproduce it
without a complex database behind the scene.

Please do if you get time. I'll happily look for a workaround. I don't
want to spend time developing pgAdmin III further, but bug fixes are
another matter.

Regards, Dave.