Es läuft...

[MartinHan]

Hallo,

ich habe diesen Post auch um Datenbank Forum gepostet.
Es haben mir die Acsess-Experten und die Datenbank-Experten geholfen, beiden schulde ich Dank!
Ich bitte um Verständnis!

nach vielen Fragen, die ich hatte und die alle kompetent beantwortet wurden, kann ich jetzt mittteilen, das mein System produktiv ist.
Kurz nochmal zur Klärung:
Hintergrund ist eine Ballettschule mit ca. 500 Schülern, 1300 Personen, Lehrkräften, Lastschrifteinzug etc. .
Es ist jetzt nicht die riesige Datenmenge, das System ist aber schon verzwickt.
Der eine oder andere mag lächeln, aber es ist ein Unternehmen, mit mehreren Mitarbeitern und mit Zugriff auif die Konten der Kunden, da ist Sorfalft gefragt...
Lange Jahre lief das unter MS Aceess ganz gut.
Aber aus internen Gründen entstand die Forderung, das mehere Mitarbeiter (nicht Kunden!) mit der Db an unterscheidlichen Standorten arbeiten wollten.
Das schafft Ms Access nicht...
Ich habe dann die Daten auf MS SQL überführt, für mich bis dato Neuland, FE ist immer noch Access.
Aber es hat letzendlich funktioniert.

Die Anwendung ist auf meheren Rechnern installiert, ist stabil und performant!
Auch ein CCM-System mit unterschiedlichen Umgebungen ist eingerichet.

Ich habe da noch eine Frage bezgl. Backup, aber dazu melde ich mich da noch mal.

Danke an das Forum für die Unterstützung!

Martin

[Bitsqueezer]

Hallo Martin,

klingt ja gut, ein guter Schritt auch zur Migration auf SQL Server Backend.
Ich empfehle Dir, Deine Datenbank in Hinsicht auf DSGVO zu überprüfen, da es um personenbezogene Daten geht.

Backups kannst Du mit SQL Server automatisiert einrichten. Wenn Du die gewünschten Optionen zum Backup mit SSMS eingestellt hast (findest Du per rechter Maustaste auf den Datenbanknamen), gibt es oben im Dialog ein kleines Script-Icon, damit kannst Du das als Skript in SSMS ausgeben.

Das kannst Du dann im SQL Server Agent (findest Du ganz unten in SSMS in der Objektliste) das Skript angeben und einstellen wann und wie oft es laufen soll.

Das Frontend benötigt keinen Backup (außer Deiner Entwicklungsdatenbank). Du solltest immer eine Kopie des aktuellen Frontends für User unerreichbar zur Verfügung haben, die kannst Du dann bei Bedarf beim User drüberbügeln. Das setzt natürlich voraus, daß in den Frontends keine eigenen Daten mehr gespeichert werden, sondern alle Daten auf dem Server sind.
Manche kopieren auch einfach beim Start über eine Batch-Datei jedesmal das Frontend zum User. Das hilft dann auch, wenn es eine neue Version des Frontends gibt, die so immer automatisch aktualisiert wird.

Gruß

Christian

[MartinHan]

Hi,

Christian danke für deinen Beitrag.
Ich nutze SQLEXPRESS, da gibt es diese Jobs leider nicht.
Ich habe es in der Entwicklungsumgebung, da ist die DB lokal auf meinem meinem Rechner, geschafft, sqlcmds über ein Shell Script abzusetzen. Im Access FE gibt es einfach nur einen Button und da steht BACKUP drauf und schon rennt das los...

sqlcmd -S .\ -i C:\DbAdcServer\sqls\Sicherung\Produktionbackup.sql -o C:\DbAdcServer\Returns.sql

Nur auf dem Server rührt sich nichts, der Befehl wird dort schlicht ignoriert...
Ich habe mit sqlcmd --version getestet und es wird mir die Version v1.8.0 abgezeigt, die ich vorher mit

winget install sqlcmd

installiert hatte.

Der Backupbefehl in der sql-Datei klappt direkt auf dem Server auch problemlos.
Also welches Häckchen habe ich übersehen?

Gruß

Martin

[PhilS]

sqlcmd -S .\ -i C:\DbAdcServer\sqls\Sicherung\Produktionbackup.sql -o C:\DbAdcServer\Returns.sql

Das ".\" als Servername kommt mir seltsam vor. - Hast du überprüft, dass das so wirklich funktioniert?

Mir ist bisher noch nicht klar, in welchem Kontext diese Befehlszeile ausgeführt wird bzw. werden soll.

[MartinHan]

Hi,

ja habe ich. .\ ist der Servername, wenn man sich lokal anmeldet, wenn also die DB auf dem gleichen Rechner ist, wo man sich angemeldet hat.

Hier noch mal der Kontext:
Eine Mitarbeiterin gibt Daten in die DB über das Access FE ein.
Am Anfang des Monats wird aus den Verträgsdaten der Schule eine xml-Datei erstellt, die Lastschriften von den Kunden einzieht. Jeder Vertrag hat ein Konto, bei dem diese Transaktion vermerkt wird.
Bevor man das macht, ist es sinnvoll, das in einer Testumgebung zu testen. Es können sich immer durch Fehleingaben Datenfehler einschleichen. Also wird der Prodbestand mit backup erstellt und in der Sandboxumgebung mit Restore hergestellt.
Dann wird dort die Lastschrift getestet und wenn alles geklappt hat, in der Produktion wiederholt und die XML-Datei anschließend zur Bank geschickt.
Das Ganze dauert nicht länger als 10 Min, wenn es eben technisch unterstützt ist.
In dem FE gibt einen Button Backend, löst man diesen aus, wird ein sqlcmd string erstellt, so wie er oben abgebildet ist. Diese wird per Shellsript ausgeführt. Die Protokolldatei wird ausgelesen ob das backup erfolgreich war. In der mit -i gekennzeichnetn Datei steht der eigentlich Backup Befehl.
Danach wird der restore für die Sandboxumgebung abgesetzt, auch über ein sqlcmd.
Das Ganze hat eben den Charme, das das FE nicht verlassen werden mss. Man wird duch ein- und ausblenden von Bottons durch den Prozess geführt, ein Wizzard sozusagen.
Natürlich geht das mit SSMS auch, nur wenn es quasi automatisch geht, fände ich es besser...
Meinst du nicht?

Martin

[Bitsqueezer]

Hallo,

also lokale Anmeldung geht für gewöhnlich mit "localhost", wenn man das TCP/IP-Protokoll benutzt oder "(local)" (mit Klammern), wenn man Shared Memory verwendet.

Darüber hinaus brauchst Du ja kein sqlcmd, Du kannst den Backup auch "ganz normal" als Stored Procedure zusammenstellen und diese dann mit Access ausführen.

Das Testen würde ich ggf. einfach mit Testtabellen durchführen, auch wenn der Backup grundsätzlich natürlich richtig ist und regelmäßig gemacht werden soll. Du kannst ohne Agent auch einfach den Windows Scheduler dazu verwenden.

Auch kann man die Daten beim Einlesen natürlich schon auf Fehler überprüfen und den Import entsprechend abweisen.

Gruß

Christian

[MartinHan]

Hallo,

bezgl. der Datenfehler habe ich schon Pferde kotzen sehen...
Was die machmal durch ungewollte Tastenkombinationen erzeugen konnten, Zeichen die man nicht sieht und die erst bei der Bank bemerkt werden.
Ich hätte das nie für möglich gehalten...
Bei Einlesen der XML-Datei im Banking kommt aber nur: die XML-Datei ist fehlerhaft...toll, wo denn, warum denn?
Deine anderen Vorschläge werde ich mir ansehen.

Danke dafür!

Martin

[PhilS]

Was die machmal durch ungewollte Tastenkombinationen erzeugen konnten, Zeichen die man nicht sieht und die erst bei der Bank bemerkt werden.

Nur mal so nebenbei:
Im Verwendungszweck einer Banküberweisung ist nur eine überschaubare Auswahl an Zeichen zulässig. Man könnte auch schon bei der Eingabe überprüfen, dass sich keine anderen Zeichen in dem entsprechenden Textfeld befinden.

[PhilS]

ja habe ich. .\ ist der Servername, wenn man sich lokal anmeldet, wenn also die DB auf dem gleichen Rechner ist, wo man sich angemeldet hat.

Der Punkt als virtueller Alias für den lokalen Server ist mir bekannt. Der Backslash wird verwendet um einen Instanznamen anzugeben. - Einen Backslash zu verwenden, wenn dann gar kein Instanzname folgt, erscheint mir widersinnig. - Vielleicht funktioniert es trotzdem.

In dem FE gibt einen Button Backend, löst man diesen aus, wird ein sqlcmd string erstellt, so wie er oben abgebildet ist. Diese wird per Shellsript ausgeführt. Die Protokolldatei wird ausgelesen ob das backup erfolgreich war. In der mit -i gekennzeichnetn Datei steht der eigentlich Backup Befehl.

Zu dem "per Shellscript ausgeführt" finde ich die Informationen noch etwas spärlich.
Hast du dasselbe Script schon mal manuell ausgeführt?
Werden dabei evtl. Fehlermeldungen ausgegeben?

Wenn die ganze Aktion sowieso durch den Benutzer gestartet wird, könntest du die SQL-Statements aus dem Script auch direkt ausführen. Entweder, wie von @Bitsqueezer vorgeschlagen, in einer Stored Procedure, oder auch einfach als Text einer Pass-Through-Abfrage.

[MartinHan]

Danke,

werde ich mir ansehen.

[MartinHan]

Hi,

Das mit dem Überprüfen der Zeichen habe ich natürlich gemacht, kommt auch nicht mehr vor.  Knock on wood..

Gegeben sei, das die Berechtigungen stimmen, dann wäre das mein Plan:

1. Backup durchführen

In Access lege ich im Backupverzeichnis einen neuen Ordner an, mit einer Backupdatei.
Diesen Pfadnamen übergebe ich einer SP, die den Backup ausführt
Die SP schreibt bei Erfolg diesen Namen in eine kleine Tabelle


2. Restore

In Access aktualisiere ich diese Tabelle und wähle einen Backupsatz aus.
Dieser kann als input für einen Restore der gleichen Stage oder einen anderen dienen, die zweite SP.


Zwei klicks...


Sollte klappen, so der Plan

Gruß

Martin

[MartinHan]

Hi,

die Backup SP habe ich erstellt und die works as designed: macht den Backup und schreibt eine Zeile in eine Tabelle, die ich im Access sehen kann.

Ich habe auf dem Server 3 Datenbanken, wo soll ich die SP am besten hinstellen? In der Master DB?
Oder jeweils redundant in den drei DB's, das hört sich irgendwie nicht gut an...
Wird sie dann auch überall gefunden wenn sie im master steht?
Sorry, ist für mich noch Neuland.

Gruß Martin

[PhilS]

Ich habe auf dem Server 3 Datenbanken, wo soll ich die SP am besten hinstellen? In der Master DB?
Oder jeweils redundant in den drei DB's, das hört sich irgendwie nicht gut an...
Wird sie dann auch überall gefunden wenn sie im master steht?

Eigene Objekte in der master DB zu speichern ist aus meiner Sicht durchaus zulässig, wenn es sich um allgemein verwendbare Tool-Objekte handelt, die so robust programmiert sind, dass sie entweder universell verwendbar sind oder die Funktion mit brauchbaren Fehlermeldungen verweigern, wenn die Voraussetzungen nicht gegeben sind.

Die Prozedur mehrfach redundant zu erstellen, halte ich eher für eine ungünstige Idee. - Zumindest dann, wenn man davon ausgehen kann dass es immer mehrere betroffene Datenbanken gibt.

Es gibt noch eine weitere Möglichkeit: Du kannst die eine eigenen "Tools" Datenbank auf dem Server erstellen, in der du solche übergreifenden Prozeduren und ihre Objekte speicherst.

In der master Datenbank sollten Stored Procedures aus allen Datenbank gefunden werden, solange es keine lokal SP mit gleichem Namen gibt.
Du kannst aber auch den Namen explizit angeben, z.B.:

Code [Auswählen] Erweitern

EXEC tools.dbo.BackupDbWenn sich die Prozedur in einer "tools" Datenbank befindet.

[Bitsqueezer]

Hallo,

so eine eigene "Master"-Datenbank ist durchaus vorteilhaft. Z.B., wenn man eine eigene Benutzerverwaltung hat und nicht für jedes neue Datenbankprojekt das Rad neu erfinden will.

Damit man nicht den Datenbanknamen vor einen Objektnamen voranstellen muß (was unpraktisch ist, wenn man mal die Datenbank umbenennen will), dann empfiehlt es sich, dafür ein Synonym anzulegen:

https://www-tutorialsteacher-com.translate.goog/sqlserver/synonyms?_x_tr_sl=en&_x_tr_tl=de&_x_tr_hl=de&_x_tr_pto=rq

Das ist quasi ein Alias für Datenbankobjekte. Da kann man dann z.B. "BackupSP" als Name hinterlegen und das Synonym ersetzt das intern gegen "tools.dbo.BackupSP". Wenn sich in den Tools was ändert, muß man dann nur an einer Stelle suchen, sehr praktische Sache. Darüber hinaus kann man ihnen auch eigene Rechte vergeben, die sich auf das Sysnonym beziehen.

Gruß

Christian

[MartinHan]

Hi,

ich bedanke mich für eure Beiträge.
Ich hoffe auch nicht zu langweilen, aber ich hoffe auch, das meine Fragestellungen von allgemeinem Interesse sind.
Denn das ist ja der Sinn dieses Forums!
Aber Schritt für Schritt, ich werde jetzt erstmal mit der master-db anfangen und wenn die SP alle stabil laufen, mich mit den Tools beschäftigen.
Bis jetzt läuft in der Produktion alles stabil, auf 3 Lapptops und auf dem Server...
Der "Point of no Return" ist erreicht, also nur nach vorne!

Danke!

Martin