Subject | Re: CAST() string as BLOB for use as a memo field in VFP |
---|---|
Author | Bhavbhuti Nathwani |
Post date | 2007-11-20T10:02:55Z |
Hi Helen
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> Write a view that returns the string from the dynamic data. Include
the pertinent key field(s) in the view and hey presto! you have a
virtual table that you can join to or subselect from.
>
> In Fb 2 and above you can also vary this option by using a derived
table instead of a view.
OK, thanks I will start thinking in these terms. The view concept is
more clearer (with my ltd. knowledge) where I have defined a view for
each table that needs a narration, which does concatenation as
required and when required joined to the flat cursor I am thinking of
and having the narrations ready. One thing I will miss is user
modifications from a table/record level. Now in such a situation the
user will have to modify the view to get the desired narration
format/layout.
> No. A function is a device that operates on supplied arguments
directly and returns a scalar result. A procedure operates on data
and optionally takes input parameters and optionally returns *a set*.
Thanks for clarifying my misunderstanding and this has brought to
light that in VFP I use pure UDFs in SELECT statement, thus the need
to pass everything as parameters.
>"executable" SPs that return a single-row set.
Is it efficient to have "executable" SPs called in SELECT statements
which might return the narration (instead of the view I just agreed to
:))?
Maybe I can have an "executable" SP for each table that requires a
narration. Maybe I can pass the iID to be used in the WHERE for the
row the "executable" SPs is supposed to generate the narration for,
the returned SP field I can store in the mNarration in the field of
the returned cursor. Maybe I can define "executable" SPs on the fly
based on the code stored in a table/field, Maybe...
>you indicate here a lack of understanding of the difference between a
UDF and a stored procedure.
Yes I confess :(
> And, all that said, never ignore the fact that all operations in
Firebird occur inside transactions that isolate one bunch of work from
another.
OK, I will keep that in mind.
Thanks for taking time out to write a detailed explanation