🚀 go-pugleaf

Thanks Vladimir.

That did the trick.  It has worked every time I tried it after making the
fixes you pointed out.  I am guessing that it was the opening of the DB
twice that was the principal culprit.

In fact, I noticed the second error you identified last night, and fixed it,
so it does not seem to be implicated.

Regarding your use of try/catch vs your idea of using try/__finally, I would
suggest the following (which I intend to try/develop in due course anyway).
;-)

<totally untested code>
class DB {
  private:
    Variant catalog, connection;
    bool connected;
    void Disconnect(void) {
      if (connected) {
        connection.Exec(Function("Close"));
        // is the following necesary - I doubt it (because
        // of the bad effect of connecting to a DB with
        // both the catalog and connection objects)
        // but I want to be sure
        catalog.Exec(Function("Close"));
        connected = false;
      }
    };
  public:
    DB(void) : catalog(null), connection(null), connected(false) {};
    explicit DB(const std::string& ConnectionString) {
      Connect(ConnectionString);
    };
    ~DB() {
       if (connected) Disconnect();
    };
    void Connect(const std::string& ConnectionString) {

       if (connected) Disconnect();
       catalog=Variant::CreateObject("ADOX.Catalog");
       catalog.Exec(Function("Create") << ConnectionString);
       connection=catalog.Exec(PropertyGet("ActiveConnection"));
       connected = true;
    };
    template <class T>
    void FetchFieldByName(const std::string& FieldName, T& Value) {
      // to be figured out later
    };
    template <class T>
    void SetFieldByName(const std::string& FieldName, T& Value) {
      // to be figured out later
    };
    // additional functions for getting/processing records, submitting SQL
statements, &c.
};
</totally untested code>

What do you think of this approach?  With something like this, we can ensure
that everything is cleaned up regardless of whether or not an exception has
occured.  And, as you can probably tell, I am trying to make this interface
in such a way that the using code need know only about C++ and the STL.  I
haven't yet figured out how to deal with the fact that the header carries
knowledge of ADO into all compilation units using it, or even if I need to
(this arises from the need to use a couple Variant data members and the
template member function FetchFieldByName).   I know I can do it by making
one or more auxiliary classes, and forward declaring them just before my DB
class (but this means creative use of smart pointers to), and just declaring
the member functions of DB, each of which would just dispatch the call to
the appropriate member function of the appropriate auxiliary classes.  Then,
the only compilation unit that would have any direct information regarding
ADO and Variants &c. would be the implementation file for DB (which could
well contain the declarations and implementations of any auxiliary classes I
use).  If I am not mistaken, using this approach, if we decide to use, say,
Oracle along with SQLAPI++, the only file we'd need examine is the
implementation file for this class and the auxiliary classes, and
reimplement those using primarily the capabilities of SQLAPI++ (ignoring
minor differences in how MS and Oracle interpret the SQL standard).  Right?

I am also considering designing a transaction class, with an explicit
constructor taking a standard sequence container (i.e. std::list,
std::vector, std::deque) or strings, each of which would be an SQL
statement, as the second argument, the first being either a reference to an
instance of my DB class or the connection string required to connect to a
DB.  There would be an inline member function to add SQL statements to the
end, or possibly the beginning, of the container.  Finally, the begin
transaction statement to be issued to the DB would occur in the constructor
and the end/rollback transaction statements would be in the destructor, and
there'd have to be one function, to be explicitly called by the using code,
that submits the SQL statements in their entirety to the DB (and of course
sets a flag that tells the destructor whether to issue the commit or
rollback statements).

I favour this over using __finally since with this approach, we can obtain a
comparable benefit to that provided by __finally without resorting to an
extension not supported by any other ANSI compliant compiler (to my
knowledge).

Cheers,

Ted