VB oder SP

[MartinHan]

Hallo Christan,

danke für deine Antwort.

Ich habe mir etwas gebastelt, was mir die Daten aus Produktion in die Umgebung Sandbox kopiert.
Dank sauberen RI-Datenmodell muss ich nur die Personen löschen und alle davon abhängigen Tabellen sind leer.
Dann bau ich sie "von unten" wieder auf.
Die dafür notwendigen Scripte fasse ich in einer Batch-Datei zusammen, die dann losrennt.
Wunderbar!

Das gleiche Prinzip werde ich jetzt für den Import aus Produktion anwenden, damit die STP nicht wieder futsch sind...

Ich habe auch VS, aber das ist mir ehrlich gesagt zu komplex. Müsste mich da einarbeiten. SSMS reicht mir momentan noch.
Das wichtigste ist, das die Produktion auf mehreren  Rechnern performant läuft und alle zufrieden sind.

Mit dieser kleinen Funktion rufe ich die Stp auf:

  Public Function call_stp(strsql As String, strconn As String, strstpname As String) As Long
   
   '
   ' parameter:
   '
   ' strsql: sql string mit Exec stpname und parameter
   ' strconn: Connention Sting
   ' strstpname: Name der STP
   '
       
    On Error GoTo myerror

    Dim db1 As database
    Dim qdf As QueryDef
       
    call_stp = 0
   
    Set db1 = CurrentDb
   
    ' Create or reuse a pass-through query
   
   Set qdf = db1.CreateQueryDef("")
     
    ' Configure the pass-through query
    With qdf
   
       .Connect = strconn
       .sql = strsql
       .ReturnsRecords = False ' No records are returned for a backup operation
   
       ' Execute the pass-through query
       .Execute
       
    End With
   
   
CleanUp:
    ' Clean up objects
    If Not qdf Is Nothing Then Set qdf = Nothing
    If Not db1 Is Nothing Then Set db1 = Nothing
    Exit Function
   
myerror:
    MsgBox "Fehler in STP: " & strstpname, vbCritical, "Fehler in STP"
    MsgBox Err.Description
    call_stp = 8
    Resume CleanUp
                       
End Function

[Bitsqueezer]

Hallo Martin,

wenn Du bereits VS hast, probier's doch einfach mal aus. Falls noch nicht gemacht, installiere Dir die SQL Tools in VS, das ist ein Addon von MS.

Damit kannst Du vor allem Schema Compare machen und siehst dann sofort den Unterschied zwischen der Entwicklungsdatenbank und der Prod-Datenbank. Also z.B. alle SPs, die voneinander abweichen, mit Anzeige der Zeilen, in denen sich was geändert hat. Oder wenn Du eine neue SP gebaut hast, die noch nicht auf der Prod ist oder auf der Prod eine, die Du in Dev schon entfernt hast - usw. Das alles natürlich mit ALLEN Objekten der Datenbank.
Den Rest von VS mußt Du dazu nicht verwenden, das Tool alleine hilft schon sehr.
Hier mal ein paar Infos dazu. Es geht nur um den Part "Schema- und Datenvergleich".
https://visualstudio.microsoft.com/de/vs/features/ssdt/

Gruß

Christian

[MartinHan]

Hallo Christian,

hab vielen Dank für deine ausführlichen Mails-
Ich habe mir mal das VS angesehen, wow, ein sehr mächtiges Tool.
Da muß man aber viel Rotwein bei trinken um das alles zu verstehn...etwas für lange Winterabende-

Was das Datendesign angeht, ist meine Anwendung eher stabil, es gibt mal kleine Anforderungen aber die kann ich noch "zu Fuß" erledigen.
Momentan steige ich ein in die STP, die mir sehr gut gefallen.
Ich kann mir vorstellen, alle INSERT, UPDATE und DELETE Befehle von VBA nach STP zu portieren.
Ich habe da aber keinen Zeitdruck und die Syntax von STP ist mir noch nicht ganz umfänglich transparent, ist aber kein Geheimnis, soviel verschiedene Statements gibt es nicht. Ich muß wieder mal eine neue Programmiersprache lernen, in SQL bin ich einigermaßen fit.

Danke nochmal!

Bis dahin!

Martin

[Bitsqueezer]

Hallo Martin,

wenn Du SQL von Access meinst, glaub mir, hast Du noch seeehr viel zu lernen. Access beinhaltet das wohl kargste SQL aller Datenbanken, die ich kenne. T-SQL von SQL Server hat alleine für einen einzigen Befehl wie SELECT oder UPDATE so dermaßen viele Syntaxvarianten, daß man sie nicht alle auf einmal lernen kann.

Ich will Dich aber nicht entmutigen, sondern im Gegenteil: Sehr gute Entscheidung, Dich damit näher zu befassen. Das Wissen um SQL aus Access ist ein sehr guter Einstieg, aber um die Vorteile von SPs zu entfesseln, mußt Du schon noch einiges dazu lernen.
Auf jeden Fall ein Tip: Versuche nicht (nie) prozedurales Denken auf SPs anzuwenden. Auch wenn eine SP wie eine Prozedur von oben nach unten funktioniert, und auch einige Elemente wie WHILE oder GOTO oder IF usw. kennt, ist die oberste Direktive (um es mal trekkiehaft auszudrücken) Set-based Denken. Also statt eine WHILE-Schleife zu durchlaufen, um Daten eines Datensatzes in irgendeiner Form zu verarbeiten, heißt es hier: Daten sammeln, filtern, verarbeiten, als Ganzes, nicht zeilenweise. Weniger "Programmlogik", mehr SQL-Logik. Dann kann man das meiste dabei herausholen.

2. Tip: Wenn Du kompliziertere Verarbeitungen brauchst, solltest Du Dir als erstes CTEs anschauen (Common Table Expressions). Klingt kompliziert - ist es aber gar nicht. Das sind einfach gesagt Unterabfragen, die man an die nächste Unterabfrage bis hin zur Endabfrage weiterreicht, wobei jede dazwischen alles aus allen vorangegangenen verwenden kann. Das geht natürlich auch mit Access SQL, wenn man eine extreme Klammerorgie und unübersichtliches SQL verwendet und dabei riskiert, daß Access irgendwann aufgibt und meint, das sei zu kompliziert und müsse jetzt aufgeteilt werden.
Wenn Du einmal die Vorteile von CTEs gesehen hast, willst Du nichts mehr anderes...

Kleines CTE-Beispiel:

Code [Auswählen] Erweitern

WITH qryPersonen AS
(
    SELECT ID_Person
          ,PersonName
    FROM Personentabelle
)
SELECT B.ID_Bestellung
      ,qP.PersonenName
FROM Bestellungen AS B
INNER JOIN qryPersonen AS qP
    ON qP.ID_Person = B.ID_Person
Das ist jetzt ein Gaga-Beispiel, aber so simpel funktionieren CTEs. Alle Unterabfragen können so schön voneinander getrennt werden und am Ende die Endausgabe formuliert werden. Wenn Du dann feststellst, daß CTEs auch rekursiv funktionieren, hast Du eine Besonderheit festgestellt, die in Access SQL schon nicht mehr funktioniert...

Weiterhin würde ich an Deiner Stelle aber nicht empfehlen, die Standard-INSERT/UPDATE/DELETE-Befehle in SPs zu portieren. Das ist eine reine Qual, außer Du hast ein Tool, das diese automatisch zusammendengelt. Und das bei jeder Änderung im Tabellendesign die SPs automatisch anpaßt... weiterhin der Tip: Laß Access das selbst regeln mit gebundenen Formularen.

Was VS angeht: Auf jeden Fall mächtiges Tool.
Ich meinte aber wirklich nur das Schemadesign-Compare, das ist sehr simpel anzuwenden. Wenn Du das startest, findest Du oben zwei Felder, da mußt Du einmal die Connection zur einen und zur anderen Datenbank angeben, dann klickst Du Compare - und dann schaust Du Dir an, wo die Unterschiede liegen. Die kannst Du je nach Richtung, die Du gewählt hast, auf die Zieldatenbank automatisch anwenden lassen, oder Du kannst ein Skript erstellen lassen, daß diese Änderungen durchführen würde und das Du dann noch anpassen kannst, oder Du verwendest den Output, um das manuell zu übertragen. Wie Du willst. Außerdem kannst Du nach dem ersten Vergleich per Häkchen in der Mitte die Objekte ausblenden, die Dich nicht interessieren, z.B. die User oder Views oder Tabellen, die Du ausschließen willst. Beim nächsten Compare werden die dann ausgegraut.

Das geht auch mit Data Compare, aber das ist schwieriger. Verwende ich selbst auch nicht, da es nicht immer richtig ist, was verglichen wird, je nach Daten. Da muß man sich länger einarbeiten und ist immer vom jeweiligen Design abhängig. Beim Schema Compare ist es VIEL einfacher und ein Tool, was ich auf jeden Fall empfehlen kann.

BTW: Wenn Du in SSMS das Datenbankdesign anpassen willst und es Dir sagt, daß das nicht zu speichern wäre, gehe dazu in die Optionen und schalte die Option ab, die das Speichern verhindert. Näher beschrieben hier:
https://learn.microsoft.com/de-de/troubleshoot/sql/ssms/error-when-you-save-table
Das ist eine der lästigsten Voreinstellungen. Problem ist, daß eine bestehende Tabelle nicht ohne weiteres geändert werden kann, besonders wenn schon Daten enthalten sind. Du kannst ein Feld anfügen, aber nicht mittendrin einfügen. Wenn Du die Option rausnimmst, dann erstellt SSMS im Hintergrund ein Skript, daß die Tabelle neu erstellt, alle Referenzen auf die alte entfernt, alle Daten in die neue transferiert und alle Referenzen wiederherstellt sowie die Tabelle wieder auf den alten Namen stellt, sobald die alte gelöscht wurde. Das geht alles in wenigen Sekunden im Hintergrund und in all meinen Designsitzungen hatte ich damit noch nie Probleme. In Access geht sowas im Hintergrund, da gibt es die Option nicht einmal.

So, nun kannst Du erst mal was lesen und ausprobieren...

Viel Spaß weiterhin und frohe Weihnachten

Christian