[Info-ingres] FW: [Users] How to Log errors while executing ingres sql command

DATABASE

[Info-ingres] FW: [Users] How to Log errors while executing ingres sql command

Postby Paul White » Tue, 21 Feb 2006 16:52:08 GMT


-----Original Message-----
From: users-bounces+pwhite= XXXX@XXXXX.COM  [mailto:users-bounces+pwhite= XXXX@XXXXX.COM ] On Behalf Of Ronald Jeninga
Sent: Monday, 20 February 2006 6:51 PM
To:  XXXX@XXXXX.COM 
Subject: Re: [Users] How to Log errors while executing ingres sql command

Hi,

use awk, like e.g. :

ronald@serval:~/eclipse_workspace/SDMS/src> sql sdmsdb2 < /tmp/x | awk '
E_US0845 Table 'table_does_not_exist' does not exist or is not owned by
    you.
    (Mon Feb 20 08:45:31 2006)

The /tmp/x script looks like

select * from table_does_not_exist;
\p\g

select count(*) from iitables;
\p\g


The main problem is not to catch the error messages, it is the transaction logic. So if your script tries to perform multi-statement transactions, you'll end up with an inconsistent database (if you are unlucky, and programmers better not count on their luck).

HTH,

Ronald


On 20 Feb 2006 10:25:50 +0530





independIT Integrative Technologies GmbH Sitz der Gesellschaft: Schrobenhausen HRB Neuburg B 1.521
Geschtsfrer:
  Dieter Stubler, Dipl. Inform. (FH)
  Ronald Jeninga, Diplom Mathematiker
_______________________________________________
Users mailing list
 XXXX@XXXXX.COM 
 http://www.**--****.com/ 



Re: [Info-ingres] FW: [Users] How to Log errors while executing ingres sql command

Postby Roy Hann » Tue, 21 Feb 2006 18:12:19 GMT




logic.
end up
not

Amen to that, brother.  sql is really just an alias for tm, and tm was never
designed for SQL.  It was designed for QUEL, a language in which transaction
boundaries are always explicitly identified.  Also unlike SQL, QUEL
implicitly rolls back any uncommitted transactions when tm (or any other
front-end) abruptly terminates--but that's another issue (it's actually
wrong behaviour required by the ANSI/ISO SQL standard).  Considering how
much sql/tm is used, someone really ought to spend some time adapting it to
properly support SQL.  (That is probably well within the ability of a
ba{*filter*}t tinkerer but I don't currently have time myself.)

At least in an SQL script is easy to tell what the flow-of-control is, so
rediscovering the transaction boundaries is relatively easy.  (Unlike
embedded SQL applications where one generally has only two choices: either
we know it's wrong, or at best(?!) we don't have a clue!  Not a good
situation.)

Roy Hann (rhann at rationalcommerce dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"
Ingres Corporation Partner



Similar Threads:

1.[Info-ingres] [Users] How to Log errors while executing ingres sql command

2.[Info-ingres] How to Log errors while executing ingres sql command

3.[Info-ingres] RES: [Info-ingres] RES: [Info-ingres] SQL Injection attacks

> -----Mensagem original-----
> De:  XXXX@XXXXX.COM  
> [mailto: XXXX@XXXXX.COM ] Em nome de Emiliano
> Enviada em: Monday, June 12, 2006 10:06 AM
> Para:  XXXX@XXXXX.COM 
> Assunto: Re: [Info-ingres] RES: [Info-ingres] SQL Injection attacks
> 
> On 2006-06-12, Leandro Pinto Fava < XXXX@XXXXX.COM > wrote:
> > Three years ago we had a case of SQL Injection against our web
portal of
> > students's info. This portal was made using ICE and reports in 1999
> > (with very bad security control). Now we have this portal made in
PHP
> > and the possibility of SQL injection is nearly null (I think :-().
We
> > had another web application (ASP) that suffered a successful SQL
> > injetcion too. The problems were corrected as well.
> 
> And (to hook into the delightful discussion I'm having with Roy), I'll
> bet you dimes to dollars that both were using query assembly.

The ASP app was, but the ICE app was not directly. Report Writer
internally should work with query assembly when passing parameters to
run a report.

> 
> The PHP function addslashes ought to protect you if you use it
> consistently. PHP ADODb has parameter binds, which are better.

Yes.

> 
> > In our case the problems were in the application layer.
> 
> HTML injection?

No, when I said application layer, I wanted to say the problem was not
in database server.

Leandro.

4.[Info-ingres] RES: [Info-ingres] RES: [Info-ingres] SQL Injection attacks

5.[Info-ingres] RES: [Info-ingres] SQL Injection attacks

6. [Info-ingres] FW: [Openroad-users] Obtaining SQL statement that was just perfor med

7. How to Log errors while executing ingres sql command

8. [Info-Ingres] Ingres SQL question



Return to DATABASE

 

Who is online

Users browsing this forum: No registered users and 53 guest