Backup aus Access mit T-Sql erstellen

[Martinha]

Hi,

mein Anbindung von Access FE an SQL DB läuft schon sehr gut. Ich kann alle Tabellen und Sichten ansprechen...wunderbar.
Ich habe jetzt auf dem Access-FE einen Button, der eine Sicherung der DB ausführen soll.

es wird dann bei Klick folgender Befehl im shell ausgeführt:

sqlcmd -S 192.168.178.47\SQLEXPRESS -i D:\DbAdcServer\sqls\Sicherung\ProduktionSicherung.sql -o D:\DbAdcServer\Return.sql

In der angesprochenen Datei steht:

BACKUP DATABASE [DbAdcProduktionProd] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL16.SQLEXPRESS\MSSQL\Backup\DbAdcProduktionProd.bak'
WITH NOFORMAT, NOINIT, NAME = N'DbAdcProduktionProd-Vollständig Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO

In der return Datei ist danach diese Meldung:

Sqlcmd: Fehler: Microsoft ODBC Driver 17 for SQL Server : SQL Server Network Interfaces: Im Sicherheitspaket sind keine Anmeldeinformationen verfügbar.
.
Sqlcmd: Fehler: Microsoft ODBC Driver 17 for SQL Server : Der SSPI Kontext kann nicht erstellt werden.

Ich habe danach gegoogelt, aber die Ergebnisse sagen mir nichts. Ich denke es hat was mit Berechtigungen zu tun.

Für einen Hinweis wäre ich dankbar.

Martin

 

[t-sql]

Morgen, funktioniert der Backup Befehl im SSMS mit dem Benutzer mit dem Du Access aufrufst?

 

[ukulele]

Bei Verwendung von sqlcmd muss glaube ich ein Anmeldename + Passwort mit angegeben werden, zumindest wird es damit gehen. Der SQL Benutzer muss vermutlich auch NTFS-Schreibrechte auf dem Zielpfad haben, macht das ganze noch etwas komplizierter. Auch steht das Passwort dann unverschlüsselt in der dem Batch und eine Sicherung würde ich auch nicht unter C:\Program Files anlegen, aber das kommt natürlich darauf an wo deine Datenbank liegt.

 

[t-sql]

Bei Verwendung von sqlcmd muss glaube ich ein Anmeldename + Passwort mit angegeben werden, zumindest wird es damit gehen. Der SQL Benutzer muss vermutlich auch NTFS-Schreibrechte auf dem Zielpfad haben, macht das ganze noch etwas komplizierter. Auch steht das Passwort dann unverschlüsselt in der dem Batch und eine Sicherung würde ich auch nicht unter C:\Program Files anlegen, aber das kommt natürlich darauf an wo deine Datenbank liegt.

Nee, wenn der aufrufende Benutzer die Rechte hat geht's auch ohne und es muss der SQL Server Service Account Schreibrechte haben.

 

[Martinha]

Danke schon mal, werde ich nachher mal testen. Bin heute busy.

 

[Martinha]

Hi,

ich habe grade mit der UID, die ich im Access verwende im SSMS erfolgreich eine Sicherung der DB durchgeführt.

 

[Martinha]

Hi,

keiner eine Idee? Wenn nicht hat es auch nicht die höchste Prio. Ich habe heute SSMS auf dem Client installiert und kann auf die DB über Wireguard zugreifen, die bei mir an der Fritzbox hängt.
Wenn es nicht über Access geht, dann geht sichern und Backup über SSMS, wäre nur schön gewesen, alles aus eine Oberfläche zu machen.
You cant always get what you want...

Der FE über Access läuft noch nicht, aber ich denke mal das liegt an der 64bit Version von Office auf dem Client, die werde ich jetzt noch auf 32bit umstellen.

Ich werde berichten!

Martin

 

[ukulele]

Ich würde das Backup sowieso nicht auf Basis von Access machen. Entweder im SSMS, im Agent (der leider nicht bei Express dabei ist) oder als Batch in der Aufgabenplanung eine SP aufrufen oder so. Ich glaube aber dafür muss xp_cmdshell aktiviert werden. Auf jeden Fall würde ich Access aus einem Backup der DB raus halten wollen. Access ist in dem Kontext ja nur ein Frontend.

 

[t-sql]

Am besten mit dbatools als Powershellscript und dann einen Task einplanen.

 

[Martinha]

ok, danke für die Tipps, werde ich mal angehen.

 

[Martinha]

Hurra!!!

Es hat heute geklappt mit einem Laptop im Studio auf die DB hier bei mir zu Hause zuzugreifen.
Hat mich eine halbes Jahr und blood, sweat and tears gekostet.
Nur leider ist die Performance noch grottenschlecht, das wird jetzt das nächste Thema sein.
Aber der Durchbruch ist geschafft.

Ich bedanke noch mal ganz herzlich bei dem Forum, ohne euch hätte ich das nie geschafft!

Martin

 

[Dukel]

Nur leider ist die Performance noch grottenschlecht, das wird jetzt das nächste Thema sein.
Aber der Durchbruch ist geschafft.

Das hat man bei vielen Latenz Abhängigen Anwendungen.
Daher gibt es viele Webanwendungen, bei denen die Latenzen keine Rolle mehr spielen, da die DB und der Web/Appserver zusammen stehen.

Das lässt sich aber nicht so einfach lösen.

 

[dabadepdu]

Nur leider ist die Performance noch grottenschlecht

Wobei genau? Das Thema hier war ja Erstellen eines Backups, Anstoß des Backups aus der Access Anwendung?

Grundsätzlich ist in dem genannten Setting

Es hat heute geklappt mit einem Laptop im Studio auf die DB hier bei mir zu Hause zuzugreifen.

erst mal die asynchrone Übertragungsrate gängiger Internetangebote ein Problem.
Selbst Glasfaser im Studio nützt nur bedingt, wenn zuhause die Upload Rate mit VDSL (gleich dem Download Flaschenhals draußen) nur 20mbit oder so sind. Glasfaser zuhause wäre da schon ein deutlicher Schritt nach vorne.

Access ist als Mitglied der Familie ~"Fat Client" tatsächlich für den LAN Betrieb konzipiert. Die Latenzen von denen @Dukel schreibt, fallen dort nicht so sehr ins Gewicht. Eine Webanwendung mit Appserver wäre im Remotebetrieb wirklich vorteilhaft, da der Datenaustausch viel effizienter abläuft (auf Client- bzw. Protokollebene).

Da Du offenbar keine Webanwendung hast, musst Du Dir überlegen, wie Du damit umgehst. Sehr viel Finetuning in der "Anwendung", also Access, ein Neuanfang mit einer Webanwendung oder als erweitertes Finetuning, den DB Server nicht zuhause laufen zu lassen, sondern in der Cloud, um dem Flaschenhals der heimischen Uploadrate zu entgehen (Beim Remote-Speichern kehrt sich das Flaschenhalsproblem um, oft werden aber in der Praxis weniger Daten gespeichert als geladen).

Das Schwierige ist wahrscheinlich, sich mit der Idee auseinanderzusetzen, Access nicht mehr zu nutzen. Ich weiß nicht warum, aber hier im Forum scheint es ja grad eine Art Access Renaissance zu geben. Vielleicht liegt es daran, dass man in den Access zentrierten Foren keine ehrlichen, einfachen Antworten auf die systembedingten Access Probleme erhält, weil es keine gibt und niemand das hören will. (nur geraten)
Man muss sich fragen, ob man mit einem "Hobbyprojekt" und den vielen Stunden, die man bereits reingesteckt hat, so weiter arbeiten kann - und dabei eben unliebsame Kompromisse in Komfort/Funktion machen muss- oder ob man aus Gründen einen Neustart durchführen will/muss und das auch zeitlich, organisatorisch, finanziell hinbekommt.
Angenommen, es ist kein Hobbyprojekt oder eher, es ist keine Einzelplatzlösung, sollte man sich eigentlich von Access verabschieden. Angenommen es ist ein neues Projekt, sollte man am besten gar nicht mit Access anfangen oder sobald die Erkenntnis einsetzt bzw. so bald wie möglich auf ein skalierendes Konzept wechseln.

 

[Martinha]

Danke für deinen ausführlichen Post.

Wir haben uns entschlossen, den Server jetzt im Studio "zu verstecken". Man muss verstehen, das da sehr viel Publikumsverkehr ist und so eine kleiner Rechner ist schon mal schnell in die Tasche gesteckt.
So sollte die Performance völlig ausreichend sein, ist sie ja hier zu Hause auch, man ist ja im gleichen Heimnetz.
Wenn dann mal von aussen mit den Daten gearbeitet werden muss, so sind das Einzelfälle und die schlechte Performance ist dann hinnehmbar, aber es ist immerhin möglich, also deutlich mehr als heute mit der Einplatzversion.
Wenn das dann eine Weile läuft, kann man das Access-FE dann auch auf Java umstellen, nur das werde ich mit meinen 73 Jahren nicht mehr tun. Aber ich habe da wen im Auge...
Für mich ist jetzt erstmal wichtig, das die Daten in einer "richtigen" DB sind. Wie werden jetzt eine Weile parallel fahren und dann bald den Cutover durchführen.
Ich kümmer mich jetzt zunächst mal um das Backup-Restore Geschäft, was wohl mit SSMS durchgeführt wird. Technisch ist das ja kein Problem nur man muss es schulen und Ballettdamen sind nicht unbedingt so EDV-affin..
Allerdings muss ich sagen, das mir Access über viele Jahre gut gefallen hat. Es hat eine klasse Oberfläche und vor allem die Vernetzung zu den anderen Office Produkten ist sehr gut. Aber ist es leider nicht sehr stabil, entwickelt man viel, stürzt es plötzlich völlig ohne Warnung ab.
Aber es ist nur für eine Einplatzversion geeignet (wenn man die Daten auch in Access hat) und mehr auch nicht. Jede Software hat ihre Grenzen und man muss die kennen.

MfG

Martin

 

[mmarschner]

Hallo Martin

Aber ist es leider nicht sehr stabil, entwickelt man viel, stürzt es plötzlich völlig ohne Warnung ab.
Aber es ist nur für eine Einplatzversion geeignet (wenn man die Daten auch in Access hat) und mehr auch nicht. Jede Software hat ihre Grenzen und man muss die kennen.

das würde ich so nicht unterschreiben wollen.

Ich habe einige Datenbanken mit zum Teil über 200 Benutzer auf Basis von Access (FE und BE) entwickelt, die über Jahre problemlos funktioniert haben. Abstürze bei der Entwicklung haben meistens vor dem Computer ihre Ursache gehabt, aber im Betrieb ist es nie vorgekommen, dass die Datenbank gecrasht ist oder das Abstürze vorgekommen sind.

Mfg

Michael