Re: Oracle sequences / SQL recording

Edi Weitz wrote:
> It works if you replace LASTVAL with CURRVAL.

Thanks for the test and correction. I'll add the function.

> PS: While debugging this I noticed that after executing the form
>     (START-SQL-RECORDING) not all SQL commands are recording, the
>     sequence commands being amongst them.  Is this an oversight or
> are
>     certain commands not recorded on purpose?  (I personally think
> for
>     debugging it'd be nice if /everything/ was recorded.)

That's a good question. Mostly, it's stems from a design
philosophy. RECORD-SQL-COMMAND is a high-level function and is invoked
by EXECUTE-COMMAND and QUERY. However, implemention-specific SQL is
used by the low-level db-specific engines. In such cases, I've not
made calls to the high-level recording functions.

I agree, for debugging, that it might be useful to have all SQL
statements recorded. For debugging sake, one might also want all SQL
results recorded as well. I'd say one would come with at least 3
categories of sql state changers:

  1. User-specified SQL commands which are already recorded by
  execute-command and query
  2. User-implied commands. The high-level implemented functions are
  already recorded such as CREATE-TABLE which calls the recording function
  EXECUTE-COMMAND. db-specific commands, like
  DATABASE-LIST-ATTRIBUTES, which are implemented in the low-layers,
  are not recorded.
  3. non-SQL commands that change the DB state, like database creation
  and destruction

In addition to using recording for debugging, one could also wish for
being able to replay a SQL stream. non-SQL commands, like #3 above,
would be challenging because they are implemented with shell commands
or API calls.

Overall, this could represent a fair bit of redesign and added
functionality.

Kevin