firebird-automations

Commented by: Cosmin Apreutesei (cosmin_ap2) I second Mirco's idea \-\- otherwise procedures won't be re\-entrant in the same connection and there's no easy way to make them so \(you'd have...

Commented by: Cosmin Apreutesei (cosmin_ap2) On a second thought, this won't be enough for all cases \(you can still call the same procedure in the same transaction twice and the...

Commented by: @dyemanov I don't think you need to apply your fantasy\. The SQL committee had already decided everything we would implement\.

Commented by: Cosmin Apreutesei (cosmin_ap2) \> The SQL committee had already decided everything we would implement\. No good deed ever goes unpunished\.

Modified by: Sean Leyne (seanleyne) description: SFID: 807942#⁠ Submitted By: pcisar Allow for the definition of temporary tables which are only visible within the current connection context and which are...

Commented by: robert gilland (robert.gilland) I have just moved company after working with firebird since 2003, and being a major contributor to it\. My new company uses "SQL anywhere"\. I...

Commented by: Robert Gilland (robert.gilland_basx.com.au) You wouldn't believe I moved company again and have exactly the same issue\. The critical need for local temporary tables and hash tables

Commented by: robert gilland (robert.gilland) I propose this solution: Add a section in the metadata\-cache for local temporary tables\. So when compiling a stored procedure the dependency tree looks at...

Commented by: @asfernandes What I think would be a very good thing is kind of "packaged table", a temporary table defined \(and upgraded\) as part of a package body/spec\.

Commented by: @aafemt In ISQL it is already implemented as bulk\_insert\. In DSQL it is less effective than array DML\. What's the point?