Hallo,
meine Anwendung für die Schule läuft, Frontend Acces, backend Ms Sql.
Ich bin jetzt in der Optimierungsphase.
Ich kann jetzt natürlich bis ans Ende meiner Tage daran basteln und Dinge optimieren.
Eine Funktion habe ich jetzt ausprobiert:
Aufgabe: Hinzufügen eines Umsatzes zur Tabelle Umsatz
Das geht natürlich mit Vb Funtionen .addew---etc. .
Man kann aber auch eine Stored Procedure in der DB aufrufen.
Beides klappt.
Aber was ist die bessere Variante?
Nach der reinen Lehre ist es wahrscheinlich besser, alle DB-spezifischen Funktionen in die Db zu verfrachten. und dann nur noch die SP quasi als API aufzurufen.
Gibt es Meinungen dazu ?
Frohes Fest und danke für die Hilfe!
Martin
Hallo,
ZitatAufgabe: Hinzufügen eines Umsatzes zur Tabelle Umsatz
Das geht natürlich mit Vb Funtionen .addew---etc. .
Ohne nähere Infos würde mir da als erstes ein gebundenes Formular einfallen. Da braucht es weder VB (nicht eher VBA ?) noch SP.
Und bestechend einfach ist es auch.
Zitat von: MartinHan am Dezember 20, 2024, 23:22:51Aufgabe: Hinzufügen eines Umsatzes zur Tabelle Umsatz
Das geht natürlich mit Vb Funtionen .addew---etc. .
Man kann aber auch eine Stored Procedure in der DB aufrufen.
Beides klappt.
Aber was ist die bessere Variante?
Generell "Besser" ist i.d.R. schon eine Stored Procedure zu verwenden, weil man damit ein weiteres Abstraktionslayer zwischen den Datenstrukturen und der (Frontend-)Anwendung schafft. Damit macht man beiden die beiden Teile unabhängiger voneinander, da man die SP für Änderungen auf der einen oder anderen Seite anpassen kann und damit die jeweils andere Seite von einer solchen Änderung gar nichts mitbekommt. - Die Frage ist, ob das allein schon den Aufwand lohnt.
Konkret besser ist die SP, wenn man mehrschrittige Operationen hat. D.h. wenn du in einer Operation gleich mehrere Datensätze hinzufügen oder ändern möchtest. Dann lässt sich das in einer SP alles wesentlich zuverlässiger in einer Transaktion kapseln und somit zu einer atomaren Operation zusammenfassen.
Ein weiteres konkretes Argument für die SP wäre ein Berechtigungskonzept, das dem Benutzer gar nicht erlaubt einfach "freihändig" Daten in Tabellen zu schreiben, sondern nur durch den definierten Ablauf einer SP.
Für deinen Beispielfall sehe ich hier erstmal keinen Grund eine SP zu verwenden, der den zusätzlichen Aufwand rechtfertigt.
Hallo Martin,
das kann man nicht allgemeingültig beantworten, hängt immer vom Fall ab.
Ja, es kann sinnvoll sein, alle Operationen, die die Datenbank betreffen, im Backend zu handhaben. Das erlaubt auch, Zugriffe genau mit Rechten zu regeln, was je nachdem ein sehr wichtiger Punkt ist, besonders, wenn es um personenbezogene Daten geht, was man bei einer Anwendung für die Schule annehmen könnte.
Auf der anderen Seite muß man sich überlegen, wo genau man die Grenze ziehen will und wieviel Aufwand man bereit ist, zu betreiben. Ein gebundenes Access-Formular etwa ist darauf angewiesen, alle Operationen mit der Datenbank selbst zu regeln, sofern das Formular Änderungen an den Daten zuläßt. D.h., Du programmierst hier nicht von Hand alle UPDATEs/INSERTs/DELETEs, was ja gerade der große Vorteil von Access ist - schnelles Prototyping und Rapid Application Development.
Dennoch erlaubt Access Dir natürlich auch, alles selbst zu machen mit einem ungebundenen Formular. Dann mußt Du all diese Tätigkeiten im Hintergrund selbst erledigen, mußt eigene Controls entwickeln (also etwa Buttons zum Speichern usw.), den Datenaustausch dann im Detail selbst programmieren. Das ist viel Aufwand und muß natürlich auch für jedes Formular und jeden Report erneut betrieben werden.
Einzelne Werte wie einen Umsatz zu schreiben, kann man im Frontend mit VBA erledigen oder im Backend mit einer SP. Da ist dann die Frage, ob das eine oder andere besser ist, eher von anderen Dingen abhängig, etwa, ob der gleiche Vorgang aus verschiedenen Frontends durchgeführt werden soll oder anderen Tools, die dann alle eine zentrale SP verwenden könnten, da hätte die SP auch mit Zugriffsberechtigungen den Vorteil, ebenso, wenn es um komplexe Berechnungen über x Tabellen geht, die dem SQL Server alle zur Verfügung stehen. Auch hier ist die SP deutlich im Vorteil.
Wenn man eine Berechnung aus den Daten eines Datensatzes ermitteln kann, wie etwa Menge x Preis in einer Rechnung zur Ermittlung der Zeilensumme, würde man weder noch verwenden, sondern einfach ein berechnetes Feld in der Rechnungsdetailstabelle, die im Beispiel nicht persistent eingestellt werden würde und den Gesamtpreis beim Lesen der Tabelle immer automatisch mit ausgibt. Gespeichert wird dann nichts, und es braucht weder VBA noch SP. Wenn die Berechnung komplexer ist, kann man stattdessen auch eine UDF (User Defined Function) verwenden in einem berechneten Feld der Tabelle und dann auf persistent stellen. Dann wird das Ergebnis der Berechnung gespeichert, so daß eine Neuberechnung erst bei Änderung der Daten angestoßen wird. Solche verwendet man auch besonders, wenn man das Ergebnis zur schnelleren Suche indizieren möchte.
VBA und SP sind in solchen Fällen nicht nötig, es muß nichts aktiv angestoßen werden, es gibt keine Rechteprobleme und alle können die Ergebnisse jederzeit verwenden.
Es ist also immer zu überlegen, welchen Aufwand man betreiben will, wo welche Methode am vorteilhaftesten ist und die wenigsten Entwicklungskosten mit sich bringt, bei gleichzeitiger Überlegung zur Datensicherheit, die natürlich immer den Vorrang vor Aufwandskosten hat.
Gruß
Christian
Hallo,
liege ich mit meinem Vorschlag ein gebundenes Formular zu verwenden so daneben ?
Nur mal so für mich gefragt.
Hallo,
ich bedanke mich sehr für eure Beiträge, da kann man sicherlich viel drüber schreiben.
Ich bin da vielleicht etwas Oldschool (mit 73 darf ich das auch sein...), aber bin immer noch ein Verfechter des Schichten Modells, also Daten-, Logik und Präsentationsschicht, so wie die IBM uns das in zahllosen Lehrgängen beigebracht hat.
Im Idealfall könnte man dann eine Schicht durch eine andere Technologie austauschen, aber wirklich nur im Idealfall.
Bei gebundenen Formularen bin ich doch sehr direkt auf den Daten und man ist wirklich sehr schnell damit, ungebundene haben den Vorteil, das man mehr Kontrolle hat.
Ein weiterer Aspekt ist dann noch folgender: irgendwann muss ich die Anwendung in andere Hände geben und da dachte ich, das die jungen Leute heute eher mit Java programmieren und deshalb den VBA Code reduzieren möchte, so dass die Anwendung dann z.B. Java und Azure als Basis hätte. Es ist wie gesagt keine große Anwendung, ca. 20 Tabellen ca. 30 Schlüsseltabellen, ca. 60 Formulare, ca. 15000 LoC VBA. Aber es muss schon eine sehr robuste Programmierung sein, weil wir an des Geld der Kunden gehen.
Aber wie gesagt danke für eure Beiträge ich werde heute mal eine gute Flasche Rotwein aufmachen und mir alles durch den Kopf gehen lassen.
Gruß
Martin
Hallo,
Zitatungebundene haben den Vorteil, das man mehr Kontrolle hat.
Vorteil, wo soll da der Vorteil liegen ?
Im MOF gab es mal einen Kommentar (zu gebunden/ungebunden) von Josef Pötzl seines Zeichens auch Mitverfasser/Beteiligter der AEK. Also ganz sicher auch Access Kenner.
ZitatIch arbeite fast immer mit gebundenen Formulare und habe trotzdem volle Kontrolle über die Daten.
Und dieser Kommentar habe ich mir gemerkt.
Der Aufwand zur Datenvalidierung und ggf. Plausibilitätsprüfung ist ob gebunden oder ungebunden der Gleiche, aber der Aufwand zum Speichern der Daten an den richtigen Stellen (Feldern) mit dem richtigen Inhalt ist ungebunden bedeutend größer und mehr fehlerbehaftet auch.
Hallo Martin,
spricht ja auch nichts gegen "old school", bin ich auch, wenn auch "nur" 57... :)
Schichten-Modell: Die Theorie ist ja auch eine gute, aber bezieht sich mehr auf Webanwendungen, wo man ein Frontend, eine Middle-Tier-Schicht und ein Backend hat.
In Access "verschmilzt" das zu einem Frontend und Backend. Die Middle-Schicht ist der Access-Automatismus im Hintergrund, der z.B. eine Datenzeile automatisch speichert. Das ist bei einer Webanwendung die Kommunikation mit der Datenbank, die das Frontend nicht machen muß.
So schreibst Du gerade mal "Me.Dirty = False" in VBA und löst damit eigentlich ein INSERT oder UPDATE aus, mit allem, was sich daraus ergibt, das schreibst Du nicht selbst.
Das "Dumme" hierbei ist, daß diese "Mittelschicht" halt untrennbar in Access existiert und bei Wechsel der Frontendtechnologie kann diese nicht ausgetauscht werden, wenn man also Access wegläßt, gibt es keinen Ersatz für die Mittelschicht. Hat man etwa eine Webanwendung mit einem Applikationsserver als Mittelschicht, kann man hier die APIs in Richtung Frontend und Backend beibehalten und die Funktionalität in der Mitte austauschen. Allerdings ist das auch eher "ideales Wunschdenken". Die einzelnen, auch mittlerweile verfügbaren Lösungen verwenden selbst auch keine Mittelschicht, die man beliebig austauschen könnte. Wenn man z.B. PowerApps verwendet, hat dieses sein eigenes Datenbankhandling, daß der PA-Programmierer ebenfalls nicht ändern kann (noch weit weniger als der VBA-Programmierer selbständig eingreifen kann). Ebenso PowerBI oder was auch immer.
Es gibt darüber hinaus aber natürlich die Möglichkeit, die Schnittstellen direkt in der Datenbank anzubieten, das setzt aber profundes Wissen über die Möglichkeiten voraus.
Man kann beispielsweise die Tabellen per Sicherheitseinstellungen komplett "unsichtbar" machen für alle Anwendungen und alle Arbeit mit allen Frontends über Views/UDFs/SPs regeln. Das ist durchaus keine schlechte Idee, weil man so die Zugriffsrechte sehr exakt regeln kann und vor allem das DB-Design komplett (oder wenigstens weinigermaßen) von der Anwendung entkoppeln kann. Wenn Du etwa ein Feld in zwei aufteilst oder einen Feldnamen umbenennen willst, dann kannst Du das tun, mußt danach nur die zugehörigen Views etc. anpassen, so daß sie "nach außen" hin immer noch das gleiche machen. Eine View kann auch per Schemabinding an Tabellen gebunden werden, dann kann man sie mit einem INSTEAD OF-Trigger so anpassen, daß man mit einer View über mehrere Tabellen Daten ändern kann, als wäre es eine einzige Tabelle - was sonst nicht so einfach geht. Die View ist dann auch selbst indizierbar. Nachteil hier ist, daß die betroffenen Tabellen dann auch im Design nicht mehr angepaßt werden können.
So eine Schnittstelle kann man aber mit "einfachen" Views etwa sehr gut an Access anbinden und hat dann beide Vorteile: Man kann die View wie eine Tabelle mit Access verlinken und hat alle Automatismen der "Mittelschicht" von Access, die Daten automatisch durch gebundene Formulare bearbeiten zu können - und hat dennoch eine eigene Möglichkeit, die Views separat mit Rechten zu versehen, so daß man sie auch gezielt für Anwendungsfälle unterschiedlich gestalten kann. So kann man etwa einer Gruppe Zugriffsrechte auf Personen-Namen und Mailadressen geben und eine andere kann alle Daten ansehen - über zwei Views mit unterschiedlichen Rechten und Feldern, obwohl beide die gleiche Tabelle verwenden. Ist nur ein Trivialbeispiel natürlich, nicht unbedingt praxistauglich.
SQL Server bietet auch "Application Roles", was wieder ein Thema für sich ist.
Du hast also sehr viele Möglichkeiten, eine Anwendung zu gestalten. Aber insbesondere, wenn das Budget knapp ist, würde ich mir gut überlegen, auf die Automatismen zu verzichten, da sie das Highlight von Access sind und sehr viele eigene Programmierfehler beim "manuellen Design" verhindern. Wenn Du darauf verzichtest, kann man auch gleich zu einer anderen Frontendtechnologie wechseln, da man dann hier in Access keine wirklichen Vorteile mehr hat.
Beispielsweise ein .NET-Frontend, bei dem Du viele der Automatismen von Access nur noch "halbautomatisch" vorfindest und dafür die volle Freiheit in der Programmierung und grafischen Gestaltung hast (etwa ein 3D-Formular, das perspektivisch in den Raum geht und trotzdem voll funktionsfähig ist...mach das mal mit Access.. ;) ).
In Access kannst Du, einfach gesagt, eine Tabelle/eine View verlinken, Access liest die Metadaten aus, fragt, wenn es nicht selbst den PK findet, den Du dann selbst auswählen mußt, und Du kannst bereits mit Doppelklick auf den Link mit den Daten arbeiten. Und nach dem Öffnen der verlinkten Tabelle klickst Du auf Formular erstellen, suchst Dir den Typ aus, und Access baut eine komplette Benutzeroberfläche zu der Tabelle für Dich, die prinzipiell erst mal keine Zeile Code mehr erfordert, um voll funktionsfähig zu sein. Du kannst also eine komplette Funktionalität erstellen mit EINER Funktion. Such Dir mal ein anderes Frontend, was das kann.
Der Code hält sich so nun auch sehr gering, weil Du Dich i.d.R. um die Speicherung der Daten nicht kümmern mußt. Bei Designänderung der Tabelle mußt Du neu verlinken, aber alles, was die gleichen Namen hat, "kennt" seine Felder nachher auch weiterhin. Alles manuell zu erledigen, wenn Du das coden willst. Der Aufwand ist ziemlich groß, der Nutzen ziemlich gering.
Wenn man sich entschieden hat, Access als Frontend zu verwenden, kann man dennoch den Codeaufwand in VBA so gut wie möglich begrenzen. Beispielsweise ist es eher sinnfrei, in VBA durch z.B. zwei verschachtelte Recordsets aus zwei SQL-Tabellen zu schleifen, um irgendwelche Daten miteinander zu verwursteln. Genau hier ist dann die Stärke der SPs in SQL Server: Du kannst die Daten über extrem performante SQL-Befehle dort verarbeiten, wo sie bereits sind, mit getrennter Rechenpower, mit allen Vorzügen, die der Server bereitstellt.
Und wenn Du dann mal das Frontend (die Technologie) wechseln mußt, ist die komplizierte Berechnung in einer SP auf dem Server und kann einfach vom nächsten Frontend weitergenutzt werden - z.B. auch parallel zu Access von einem Reporting Server (SSRS ist in SQL Server ja schon "mit dabei"). Wenn die Berechnung nur in VBA existiert, kann der SSRS damit nicht arbeiten. Also überflüssige Arbeit UND schlechte Performance. Genau hier spielen SPs ihre Stärken aus. Nebenbei kann man hier mit "EXECUTE AS" auch noch eine Berechtigungsstuf erhöhen, wenn die SP etwa Daten benötigt, auf die der Benutzer der Access-Anwendung, der sie aufgerufen hat, keine Zugriffsrechte hat. So kann die SP damit arbeiten, auch wenn der Benutzer es nicht kann.
Für den Zweck dagegen, einfache Speicherung von Datenzeilen eines Formulares je eine SP zu bauen, das ist i.d.R. mit Kanonen auf Spatzen schießen und bietet auch keine Performance-Vorteile, da es ja nur um eine Datenzeile geht (i.d.R.). Wenn man dagegen z.B. eine CSV-Tabelle hochladen will, ist eine SP schon wieder eine bessere Lösung.
Daher sage ich ja, man kann keine generelle Antwort auf die Frage geben, es gibt nicht DIE Lösung, sondern nur die Abwägung, was im spezifischen Fall besser ist. Wenn das Budget gering ist und entsprechend die Entwicklungszeit minimiert werden muß, gibt es kaum eine bessere Frontend-Technik als Access (aber unter der Prämisse, seine Automatismen so gut wie möglich zu verwenden). Das spricht nicht dem Sicherheitskonzept entgegen, da man die Tabellen über Views etc. kapseln kann (natürlich kann man auch immer mit den Tabellen direkt arbeiten, ich persönlich versuche das immer zu vermeiden).
Wenn man ein riesiges Budget hat und am besten noch Entwicklungstools, die einem Datenklassen auswerfen für DB-Objekte, oder wo man eine Applikations-Server-Schicht aufbauen kann, um verschiedenste Frontends gegen die Datenbank abzuschotten usw. - ja, warum nicht? Kostet nur erheblich mehr, es gibt weit mehr Fehlerquellen und Performance wird auch nicht unbedingt schneller dadurch.
Wie oft wurde so eine Mittelschicht tatsächlich in den letzten Jahrzehnten mal ausgetauscht? Also in meinen >30 Jahren Berufserfahrung hatte ich das noch bei keinem Projekt erlebt. I.d.R. will man Frontends aufbessern, und da geht es meist um Geschwindigkeit, unabhängiges Arbeiten Offline oder auch Arbeiten per Internetzugriff.
Es lohnt also nicht, sich auf eine etwaige Zukunft einzustellen, die dann nie eintritt. Besonders nicht, wenn der Aufwand dann so groß ist, daß es die Nutzung der Anwendung JETZT völlig verzögert.
Gruß
Christian
Zitat von: MzKlMu am Dezember 21, 2024, 12:35:28liege ich mit meinem Vorschlag ein gebundenes Formular zu verwenden so daneben ?
Ich bin bei der Fragestellung "VB oder SP" davon ausgegangen, dass es hier nicht um eine direkte manuelle Dateneingabe geht, sondern um einen automatischen Prozess der irgendwo an einer Benutzeraktion versteckt hintendran abläuft. Also dass ein Formular, gebunden oder ungebunden, gar nicht Teil der Frage ist.
Zitat von: MzKlMu am Dezember 21, 2024, 13:49:38Ich arbeite fast immer mit gebundenen Formulare und habe trotzdem volle Kontrolle über die Daten.
Und warum nur
fast immer?
Access verfolgt einen Ansatz, der es sehr einfach macht ohne tiefergehende Programmierkenntnisse schnell zu einem Ergebnis zu kommen, dafür muss man bei höheren Ansprüchen Abstriche machen.
Natürlich kann man auch ungebunden arbeiten und selbst ein paar Klassen entwerfen die die ganze Funktionalität der gebundenen Formulare nachbilden dafür aber dann
weit mehr können als Access anbietet.
Habe ich selbst in Verwendung, aber mittlerweile würde ich so was nicht mehr in Access entwickeln.
Denn warum sollte man bei gehobenen Ansprüchen Access verwenden das nur 2% der Möglichkeiten einer vernünftigen Entwicklungsumgebung anbietet?
Hallo,
ZitatUnd warum nur fast immer?
Das weis ich nicht, denn das Zitat ist nicht von mir.
Aber "fast" ist schon OK. Es gibt manchmal Vorhaben wo ungebundene Felder Vorteile bieten.
Z.B. wenn man neue Daten immer oben einfügen will. Was gerade vor kurzem hier im Forum ein Thema war.
@klaus, das war ein Scherz ;)
@Markus Ich darf auch mal auf der Leitung stehen. :) ;D
Hi,
nachdem das Christkind weg war...habe ich etwas gebastelt und einige STP geschrieben.
Vom Prinzip her gefällt mir das schon ganz gut auch die Performance passt, wobei ich so geringe Datenmenge habe, das ein Unterschied zu VBA wohl nicht meßbar sein wird.
Ein kleines Problem gibt es aber...ich habe die DB aus der Produktion geladen...und danach waren dann die STP. die ich in der Entwicklung hatte, futsch...
Da muss man also aufpassen.
Z.B. könnte man die Prod-Daten in eine temporäre DB laden, aus der man dann die Daten in der Entwicklung auffrischt.
Man lernt nie aus...
Martin
Hallo Martin,
ja, zu diesem Zweck empfehle ich Dir, wenn Du nicht in teure Tools investieren möchtest, einfach die Visual Studio Community Edition herunterzuladen und zu installieren, dazu dann die SQL Server Tools.
Hier kannst Du dann ein Tool starten, mit dem Du Schema und/oder Daten von zwei Datenbanken miteinander vergleichen kannst. Wenn Du die Daten aus der Produktion in einem Backup auf dem Entwicklungsrechner einspielst (dort natürlich unter einem anderen Namen), dann kann Dir das Tool z.B. einfach die SPs miteinander vergleichen und Du siehst, was Du von wo nach wo laden mußt (oder nicht laden, um nichts zu überschreiben). Außerdem generiert Dir das Tool auch auf Wunsch gleich ein komplettes Skript, womit die eine Datenbank an die andere angepaßt wird.
Für professionelle Verwendung empfiehlt sich eher sowas wie RedGate, das nochmal um Längen besser ist, aber es kostet halt auch nicht wenig. Wenn kein Budget dazu da ist, tut es Visual Studio auch.
Nebenbei kannst Du natürlich auch gleich Deine Entwicklung mit Visual Studio durchführen (was nicht mein persönlicher Weg ist, aber nur, um es zu erwähnen). Man kann mit Visual Studio das Datenbankprojekt komplett übernehmen, d.h., es werden alle Entwicklungen inkl. Tabellendesign, SPs, Views usw. als Objekte in Visual Studio in einem Projekt gespeichert, und Visual Studio kann dieses Gesamtprojekt dann mit einer bestehenden Datenbank vergleichen und die Zieldatenbank anpassen. So kannst Du z.B. die Sourcecodes in VS entwickeln und dann auf die Zieldatenbank übertragen. Ebenso ist auch eine Sourcecodeverwaltung wie Github möglich, wenn man das möchte.
Ich persönlich entwickele lieber immer direkt auf SSMS, was ja auch ein Derivat von VS ist, auch wenn die Projekete, die man hier anlegen kann, nicht viel mehr als eine "Skriptsammlung" sind, mir genügt's. Aber das muß jeder selbst wissen. Für Vergleiche zwischen zwei Datenbanken nehme ich auch i.d.R. VS.
Wümsche frohe Weihnachten,
Christian
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
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
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
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:
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