Access & VBA, was ist die beste "Architektur" für eine große, skalierbare Anwendung

Question

Ich würde gerne wissen, was ist der beste Ansatz in Bezug auf Mischen, SQL & VBA. Weil ich gerade an einer riesigen Anwendung arbeite, die sich wahrscheinlich in Zukunft entwickeln wird und ich mich frage, ob ich richtig gemacht habe.

Ich habe mich entschieden, die meisten meiner SQL-Abfragen in unabhängigen VBA-Modulen "hart zu codieren", nur Werte von Kriterien (für SELECT/DELETE) oder Felder (für INSERT/UPDATE) als Parameter. Zuerst fand ich dies bequem, da ich nur einen Prozeduraufruf in meinem Formularcode machen musste und nur die gewünschten Werte meiner Steuerelemente übermittelte.

Aber das Problem ist, dass, wenn ich ein neues Feld hinzufügen, meine Tabelle umbenennen oder ein Feld umbenennen, werde ich alle Anfragen in Bezug auf diese Tabelle nacheinander neu zu schreiben ... Das ist ziemlich ärgerlich

Ich möchte zu wissen, ob es eine "Standardarchitektur" gibt, um bequem mit einer skalierbaren Anwendung in Access zu arbeiten?

Mit skalierbar meine ich die Datenbank selbst UND die Anwendungslogik.

Answer 1

... das Problem ist, dass, wenn ich ein neues Feld hinzufügen, umbenennen meinem Tisch oder ein umzubenennen, muss ich alle Abfragen neu zu schreiben über das, Tisch eins nach dem anderen

I empfehlen, dass Sie QueryDef Objekte (gespeicherte Abfragen) verwenden, anstatt den SQL-Anweisungstext in Codemodulen beizubehalten.

Wenn Sie dann Abfragen haben, die auf einen Tabellen- oder Feldnamen verweisen, der später geändert wird, müssen Sie nicht notwendigerweise manuell angeben, welche Abfragen überarbeitet und einzeln bearbeitet werden müssen. Sie könnten etwas wie swapTblNamesInQueryDefs() verwenden. Ich habe das für Tabellennamen geschrieben, aber es sollte auch für Feldnamen funktionieren.

Wenn Sie Ihre SQL-Anweisungen weiterhin in Codemodulen aufbewahren, können Sie etwas ähnliches mit find & ersetzen. Eine mögliche Komplikation ist jedoch, dass das Ersetzen von Wörtern nicht nur auf SQL-Anweisungstexte beschränkt ist. Das ist ein Problem, wenn das Zielwort an anderer Stelle in Ihrem VBA-Code vorhanden ist, aber diese Ereignisse nicht ersetzt werden sollen. Das ist kein Problem, wenn Ihr SQL in QueryDef Objekte ist.

Das Hinzufügen neuer Felder ist schwieriger. Sie könnten swapTblNamesInQueryDefs() in DisplayOnly Modus verwenden, um die SQL aus Abfragen zu untersuchen, die den Namen der geänderten Tabelle enthalten. Ich sehe jedoch keinen automatisierbaren Weg, um festzustellen, welche dieser Abfragen geändert werden sollte und die erforderlichen Änderungen vorzunehmen.