Recent changes to bugs

1st column of VIEWs are chopped off

Anonymous — Sat, 18 May 2002 13:45:32 -0000

This is a general problem that appears to affect all
database clients (I'm using PostgreSQL). The 1st
column of all VIEWs that are displayed as a list is cut
off. I noticed this because I have a VIEW with only
one column. No data appears when I look at this VIEW.

Here is a patch (hack) that corrects this bug:

[p-hoover util]$ cvs diff base.pl
Index: base.pl
===================================================================
RCS file: /cvsroot/dbengine/dbengine/util/base.pl,v
retrieving revision 1.10
diff -r1.10 base.pl
752c752
< $search = "SELECT $fields FROM $table $suche $order";
---
> $search = "SELECT 0 AS oid,$fields FROM $table
$suche $order";

Not all underscores removed.

David Hoover — Fri, 17 May 2002 15:51:59 -0000

Hi. With version 1.1 of dbengine, my tables
which have multiple underscores were displayed
with funny titles like
Summary Fund_cv
instead of
Summary Fund Cv

I made fixes in base.pl for dbengine 1.1, and then
realized that the CVS code has been completely
rewritten (looks much better structured, compared to 1.1).

I think you should be able to apply these changes
without any problem to your new code, although I
haven't tried it:

sub CreateMenu() of base.pl version 1.10 (CVS):
Change
$disp_tablename =~ s/\W|_/ /o;
$disp_tablename =~ s/\W|_/ /o;
to
$disp_tablename =~ s/\W|_/ /go;
$disp_tablename =~ s/\W|_/ /go;

Thanks,

Dave.

DBI not used in recommenede way

David Hoover — Fri, 17 May 2002 14:21:21 -0000

Hi,

In the dbengine code, I repeatedly see the following
type of query code:
$comm = "SELECT * FROM $table WHERE $uniqOID='$oid'";
$result = $dbconn->prepare($comm) ;
$result->execute;

This is not recommended practice. The way this should
be coded is (unless you have some good reason not to):

$comm = "SELECT * FROM ? WHERE $uniqOID=?";
$result = $dbconn->prepare($comm) ;
$result->execute($table,$oid);

The DBD then makes substitutions for $table and $oid,
but it handles quotes and other strange characters
correctly.
By not using the placeholders ('?') correctly, you open
yourself up to bugs or security problems which may
occur because of tablenames with weird characters in
them (because simple perl substitution is not
appropriate). Also, using the placeholders correctly
may result in a speed improvement of dbengine, and
fewer strange unexplainable bugs.

Just a recommendation. Would somebody like me to make
these changes to have them integrated into the source?

'edit' option provided for VIEWs

David Hoover — Fri, 17 May 2002 12:19:39 -0000

Now that I have VIEWs working (bugID 557185, 557202), I
realize that the dbengine 'list' presentation has an
'edit' option. But due to the oid-based edit
programming, it is impossible to really edit a view--it
fails with an error. This option should probably be
removed.

another PostgreSQL VIEW problem

David Hoover — Fri, 17 May 2002 12:15:22 -0000

Hi,

Another problem I had trying to get VIEWs to work with
PostgreSQL 7.2.1, DBI-1.21, and DBD-Pg-1.13 is that in
base.pl it is assumed that the DBI function tables() is
going to return both tables and views. But this is not
the case. With DBD-Pg-1.13, only tables are returned.
Have the DBI people clearly stated somewhere what the
correct behavior is? Tables or tables+views?

To fix this, it seems like dbengine should either have
database specific get_tables() function (which could
create a hash which also indicates if the table is
really a VIEW, so db_isView could be removed). This
get_tables function could use the newer table_info
function instead of the deprecated tables() function.

A quick fix for DBD-Pg is the following:
[p-hoover@iamac37 util]$ diff
/usr/lib/perl5/site_perl/5.6.0/ppc-linux/DBD/Pg.pm
/share/DBD-Pg/DBD-Pg-1.13/Pg.pm
190c190
< where relkind IN ('r','v')
---
> where relkind = 'r'

Is this really a DBD-Pg bug? Should it be submitted to
the DBD-Pg maintainer? Would it break other existing
client software?

VIEWs don't work with PostgreSQL

David Hoover — Fri, 17 May 2002 12:06:04 -0000

Hi,

VIEWs on my linux machine do not work with PostgreSQL
7.2.1, DBI-1.21, and DBD-Pg-1.13. The primary dbengine
problem is that the db_isView subroutine of postgres.pl
tries to determine if a table is really a view by using
dbdconn handle instead of dbconn.

Patch:
[p-hoover@iamac37 util]$ diff postgres.pl.orig
postgres.pl.fix
52c52
< my $result = $dbdconn->prepare($cmd);
---
> my $result = $dbconn->prepare($cmd);

Choice of Database can fail

Ingo Ciechowski — Mon, 17 Dec 2001 14:26:12 -0000

I found that the choice mechanism in get_databse_type()
is weak since it's not predictable in which order the
@choices array gets filled.

My MacOS X machine lists (1)Postgres,(2)Oracle,(3)MySQL
and the cis-computer.com FreeBSD machine lists
(1)MySQL,(2)Oracle,(3)Postgres....

Since the code requires the choice of (1) for Postgres
things can get buggy here :-((

However, one can manually edit the generated file
base/confdat prior to "make" and/or the file
base/dbengine.cfg prior to "make install" to correct
the database setting.