Hi, i've a problem. How to verifying result of execSql procedure of TZQuery ?
If execSql failed no result of execution o error show. Another tecnique is necessary ?
execSql certified execution
Moderators: gto, EgonHugeist
It depends on what are your purposes.
I mean .. if your query is ok, you can verify with RowAffected how many row are changed .. So if rowafected = 0 your query does not match any record.
But if the query contains error (i.e. parameters not correct) I think it is correct that Zeos raise an exception
I mean .. if your query is ok, you can verify with RowAffected how many row are changed .. So if rowafected = 0 your query does not match any record.
But if the query contains error (i.e. parameters not correct) I think it is correct that Zeos raise an exception
Sorry but this is not sufficient. Assume that sql is formally correct but a parameter is 'P' and not '24:00:00' and field time1 and time2 is TIME types. In this case the sql is execute without any error:
update prodotti set time1='p', time2='24:00:00'
time1 and time2 is updates too but this is an error the parameter time1 in input is formally incorrent. Ok I need intercept this exception. Help
update prodotti set time1='p', time2='24:00:00'
time1 and time2 is updates too but this is an error the parameter time1 in input is formally incorrent. Ok I need intercept this exception. Help
-
mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
daniele,
Problem is we don't know anything about what you are trying to do. An on what database.
Some comments
- When you try to update a TZQuery resultset by using the query's append or edit methods most severe datatype erros should be catched when you enter the data. I don't believe a dataset accepts a 'P' in a datetime column. This is the only place where zeoslb cares (a bit) about the data you enter in a database. We do this by parsing your select statement and decide what datatypes all columns have. When you afterwards update the resultset some checking will be done.
- When you provide an insert/updat/delete statement it's YOUR responsibility as a programmer to check if the provided sql/parameters are logically correct. So if you enter a string as a datetime value and your database server doesn't complain with an error, there's no reason zeoslib should complain. We don't parse your sql for an update statement. In this case I believe you best use Connection.ExecuteDirect as gto proposes. There ZQuery.execSQL may have a little more overhead.
- TZUpdateSQL is not a component you use independent from a TZQuery. t's a helper component when you want to edit a resultset that originates from a complex sql statement involving joins. It's a completely different use case.
Mark
Problem is we don't know anything about what you are trying to do. An on what database.
Some comments
- When you try to update a TZQuery resultset by using the query's append or edit methods most severe datatype erros should be catched when you enter the data. I don't believe a dataset accepts a 'P' in a datetime column. This is the only place where zeoslb cares (a bit) about the data you enter in a database. We do this by parsing your select statement and decide what datatypes all columns have. When you afterwards update the resultset some checking will be done.
- When you provide an insert/updat/delete statement it's YOUR responsibility as a programmer to check if the provided sql/parameters are logically correct. So if you enter a string as a datetime value and your database server doesn't complain with an error, there's no reason zeoslib should complain. We don't parse your sql for an update statement. In this case I believe you best use Connection.ExecuteDirect as gto proposes. There ZQuery.execSQL may have a little more overhead.
- TZUpdateSQL is not a component you use independent from a TZQuery. t's a helper component when you want to edit a resultset that originates from a complex sql statement involving joins. It's a completely different use case.
Mark
