Hi,

At May 7, 2003, 07:22, tickerboo2002 wrote:

> Before I got into Firebird and IBO the only other db programming
> experience I had was with SQL Server v7 and MSVC. On that project,
> no SQL was contained within the client sw, everything was a stored
> procedure. At the time I understood the reasons to be faster speed,
> and centralised SQL tweaking/fixes etc

Still a good concept, but to a certain extent(in my view anyway).

> Now that I'm using FB & IBO, I find all my SQL code is within my
> application and I'm using no stored procs.

> What are the pro's and con's of using client SQL or stored procs with
> fb/IBO. I sometimes read people mocking the fact that client sw
> contains SQL code, is it so bad?

No it's not. If the query is simple, I place it in the client app. If
the query would be complex(i.e. Aged Accounts Receivable, subqueries
for each columns), I use a stored procedure. Just to give you an idea
of the performance gain in this particular case: the complex query
could take 10 minutes to run on 50000 invoices, and the stored
procedure where the queries for each column are separated and not part
of a complex query, the execution and retrieval time is down to under
2 seconds. Not every comparison can be as drastic in performance
improvement. Also, stored procedures that return a result set, need
to be used within a SELECT statement to retrieve the rows.

> Lastly, are there any examples of stored procs that I can peruse to
> gain an idea of their capabilities/structure etc?

Look at the Language Reference and Data Definition Guide.
(http://www.firebirdsql.org/index.php?op=doc&id=userdoc)

Also, if you still have questions related to Firebird, you can ask
them on the ib-support Yahoo Group (to subscribe:
ib-support-subscribe@yahoogroups.com)

Hope this helps.

--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)