I considered that - I may still go there. My idea, reasonable or not,
is to basically perform all my data retrieval and storage via stored
procedures. I'm still playing with it - but it makes a lot of things
much easier from an application coding point of view. I suppose filling
a "work" table and then calling an "update" procedure isn't too terrible
- but I'd still prefer the elegance of a single procedure call. Then
the only SQL syntax used in my app would be the procedure calls.

Daniel

Svein Erling Tysvær wrote:

>In general, tables are quite good at storing a variable number of records *G*.
>What about storing the records (or the PK of the records) in a table together
>with a number obtained from a generator (same number for all records in the set)
>, and then just pass this number to the SP?
>
>HTH,
>Set
>
>--- In firebird-support@yahoogroups.com, Daniel Miller wrote:
>
>
>>Are there any plans to implement array input parameters for stored
>>procedures?
>>
>>I'm trying to use stored procedures to hide the database implementation
>>from my application - so I can change my table structure with virtually
>>no changes to my app. So far, it's gone reasonably well.
>>
>>My problem now is trying to work with a group of records as a single
>>entity. I didn't want to use array columns as this requires a fixed
>>dimension - and I wanted it variable. But now I don't see how to send a
>>variable amount of information to a procedure for storage. The only way
>>I see it now is to declare a fixed list of input parameters - more than
>>I anticipate storing, and then checking those parameters for null
>>values. This seems clumsy.
>>
>>If someone has a better idea, please share!
>>
>>Daniel
>>
>>