Das ist bestimmt möglich und sollte auch gemacht werden.
Wobei du in diesem Beispiel beachten musst, dass das Jet/DAO-Synstax ist, da db auf eine DAO.Database verweist und außerdem nicht ODBCDirect nutzt.
Noch kritischer wird die DBMS-Abhängigkeit bei ADODB, wenn man über OLEDB fährt.
Die einfachste Variante wäre einen optionalen Parameter an diese Funktion anzufügen, mit dem man die Select-Anweisung zum Ermitteln des Autowertes angeben kann.
Oder man erweitert die Klasse um ein paar Eigenschaften zum Einstellen dieser Texte.
Ich persönlich neige aber eher zu einem Ereignis, dass in dieser Funktion ausgelöst wird, und über das man dann einerseits die Select-Anweisung einspeisen kann oder überhaupt aus einer anderen Klasse die Aufgabe der Prozedur übernimmt (so eine Art Hook-Mechanismus).
In die Klasse schreibt man dann jene Anweisung, die am meisten verwendet wird und für jene DBMS, die damit nicht klar kommen nimmt man eine Hilfsklasse mit, die auf die Ereignisse entsprechend reagiert und korrigierend eingreift.
... jetzt wären wir wieder beim Thema "Detailklassen". Könnte man in VBA sinnvoll erben, würde ich sagen: bauen wir doch für die jeweiligen DBMS die notwendigen Klassen ein.
Mit den ursuper Implements-Anweisungen von VBA wird das aber ein Wartungsaufwand, wenn ein paar Prozeduren ergänzt werden, der vermutlich nur zu Folgefehlern führt, weil irgendwo doch etwas übersehen wurde zu ändern.
Daher neige ich eher zu einer "offenen" Ereignis-Schnittstelle der Datenzugriffsklassen, an die sich beliebige Klassen anhängen können.
Was aber für DBMS bestimmt noch interessant werden wird, ist so etwas ähnliches wie die
DbConnectionInfo-Klasse, mit der ich die Verbindungsdaten für die jeweiligen DBMS zusammenstelle. So eine Klasse könnte dann auch die richtigen SQL-Texte für @@Identity & Co. liefern.
)