Subject | Re: [IBO] Selectable stored procedures and IBO |
---|---|
Author | crazymenconnected |
Post date | 2007-09-07T16:13:43Z |
Hello again and first of all let me apologize for not signing my name
in the last post, it was in fact rude of me!
My name is Luis Semedo Duarte, and im a computer programmer from
Portugal, and i've been developing database applications for the last
5 years, and im now starting to develop with Firebird.
there are some manipulations and validations on the data to be made
and i find it quite impossible to do it directly on the SQL property,
and also its easier to maintain the code on the server. That way i
can just change the SQL code on the server and all the client
applications reflect that same change. If i had the code on the
application i would have to recompile and update all the clients. And
with that comes alot of headhaches.
So basicly what you advising me to do, is to use some ESP on the
UpdateSQL properties and inside that perform appropriate instructions.
So far so good. But i have on question, imagine the ESP as some
output parameters, with error codes for examples, am i still able to
return those parameters along with the SSP params?
property that made my data editable. (newbie)
By the way Helen, let me compliment on your work on the Firebird
Book, its a excellent book! Im been using it for some time, and it
has been a precious help!
Luis Semedo Duarte
in the last post, it was in fact rude of me!
My name is Luis Semedo Duarte, and im a computer programmer from
Portugal, and i've been developing database applications for the last
5 years, and im now starting to develop with Firebird.
> Well, first figure out whether it makes logical sense to edityou
> non-existent data fields. If you think it's right to do it, then
> will need to populate the EditSQL, InsertSQL and DeleteSQLproperties
> of your query, using parameterised statements targetting the tableIn fact i think i really do need to use a SSP to get the data because
> and columns of that table that you want to change.
there are some manipulations and validations on the data to be made
and i find it quite impossible to do it directly on the SQL property,
and also its easier to maintain the code on the server. That way i
can just change the SQL code on the server and all the client
applications reflect that same change. If i had the code on the
application i would have to recompile and update all the clients. And
with that comes alot of headhaches.
>[s].
> If your SSP has fields that come from multiple tables, you can't
> perform DML this way. Instead, you will need to write one or more
> executable SPs that take input arguments from your SSP set, and
> perform the separate DML statements inside that (or those) procedure
So basicly what you advising me to do, is to use some ESP on the
UpdateSQL properties and inside that perform appropriate instructions.
So far so good. But i have on question, imagine the ESP as some
output parameters, with error codes for examples, am i still able to
return those parameters along with the SSP params?
>Thanks for the hint because i thought that RequestLive was the
> Take extreme care to exclude any derived fields from your DML
> statements or ESP calls.
>
> Note, setting RequestLive has no effect whatsoever on non-updatable
> datasets. IBO makes the dataset "live" if there are valid XxxSQL
> statements provided.
>
property that made my data editable. (newbie)
> HelenThank you very mutch for your help!
> p.s. It's considered good etiquette to sign your name when you're
> asking people to help you out.
>
By the way Helen, let me compliment on your work on the Firebird
Book, its a excellent book! Im been using it for some time, and it
has been a precious help!
Luis Semedo Duarte