Office: (Office 2010) Schützen der Entwürfe in Acc2010

Meine Idee:
Öffnen einer Acc-2010-Datenbank mit dem Parameter /Runtime, sodass Unbefugte nicht mehr in den Entwürfen herumfummeln können.
Dies kann ja geschehen per .cmd-Datei, in der das so hinterlegt ist (getestet: funktioniert)
Wenn aber nun auf dem betreffenden Platz doch eine Vollversion Access 2010 installiert ist, könnte ein "superschlauer" Anwender ja die .accdb / .accde direkt öffnen.

Frage:
kann man per VBA in einer Systemvariable abfragen, ob die aktuelle Datenbank in der aktuellen Arbeitssitzung in Runtime-Modus geöffnet ist?
Wenn Nein , dann Beenden (natürlich irgendwo noch ein Hintertürchen auflassen, so dass der Programmierer selbst wieder reinkommt).

Hintergrund:
die "alten Tricks" aus Acc2003 und Vorgängern mit Ausblenden des Datenbankfensters u.a. sowie Unterdrücken der Shift-TAste (Don Karls 1.8) funzen ja so nicht mehr ab 2010.

Danke im Voraus.

:)

 

HalloWerner,

ob das geht:

weiß ich so zwar auch nicht. Aber selbst wenn es ginge, wird ein Böswilliger ja nicht davon abgehalten, "manuell" die Datenbank zu öffnen. Ohne cmd, und ohne Runtime-Option.

Wie wäre es, wenn du dem User nur eine MDE/ACCDE bereitstellst? Da kommt er auch mit einer Vollversion nur mühsam an den Code.

 

Hi Martin,

Aber trotz .mde / .accde könnte der "Böswillige" in Entwürfen von Tabellen / Abfragen / Makros immer noch rumfummeln, meine ich.
.mde / .accde schützen doch IMHO nur die Entwürfe von Formularen / Berichten / Modulen, oder?

Gehen wir von einer Backend-Frontend-Architektur aus, müsste das Problem für die FE und die BE ggf. separat angegangen werden.

 

Ich habe aktuell hier kein Access 2010, aber ist das wirklich so?
Unter Access 2007 waren diese "Sicherungsmechanismen" durchaus noch möglich, es kann natürlich sein, dass der sog. BackstageBereich von Office 2010 hier weniger bzw. mehr zulässt.

In einer kompilierten DB (*.accde/*.mde) ist an die Entwürfe der Objekte nur mit zusätzlichem Aufwand ran zu kommen. Oder bietet hier Access 2010 auch mehr als Access 2007 *eek.gif*

 

Ja, das stimmt. Aber da steckt ja auch die meiste Arbeit drin. *Smilie

 

Habe es gerade mal schnell getestet:

• aus einer .accdb (BAckend, nur TAbellen) eine .accde erzeugt
• diese .accde geöffnet
• Auch in dieser konnte ich TAbellen /Abfragen / Makros ändern/neue anlegen usw
• Nur Formulare / Berichte / Module sind entwurfsmäßig geblockt

So war das aber schon immer, seit Access 97 / 2000 / 2003 / 2007 bis 2010 durchgehend immer gleich!

 

Vielleicht kannst du das noch durch das rudimentäre Berechtigungssystem verhindern....

Ansonsten: Ja, es ist unsicher. Für Hochsicherheitsanwendungen ist Access das falsche Werkzeug. Selbst wenn du das absichern hinbekommst, kann man immer noch z.B. Datensätze löschen oder MwSt-Sätze ändern....

 

Ok, bleibt noch das Thema Kennwort, ausblenden des Navigationsfensters, verhindern der SHIFT-Taste.

"Sicherer" wirst Du eine DB nicht bekommen...
Makros sollten nur in geringer Anzahl (wenn überhaupt!) vorhanden sein, an Module kommst Du in einer kompilierten DB nicht mehr (ohne weiteres) ran.

 

Hallo,

ja, das sollte hoffentlich immer noch mit dem folgenden Code gehen: Code:

Das setze ich seit geraumer Zeit in meinen Anwendungen (mdb < A2007) ein. Was den Fehler 5 auslöst kann ich grad nicht sagen.

 

Anne, Schatz *wink.gif*

Dein Code wird sofort verhaftet und ausprobiert.
Ich gebe so schnell wie möglich Rückmeldung, ob das in Acc2010 noch funzt.

Benny,
trotz Ausblendens des Navigationsfensters verbleibt nach erneutem Öffnen der purpurfarbige Reiter Datei --> DatenschutzOptionen --> Optionenbox --> Aktuelle Datenbank --> alles kann wieder aktiviert werden !!

 

Martin,

Das hat MS beim Dateiformat .accdb DEMONTIERT!
Kompromiss: man arbeitet mit dem Programm Access 2010, aber die Datenbankdatei hat noch das alte Acc2003-Format .mdb!
Dann taucht auch wieder der Datensicherheitsassistent im Backstagebereich auf.
Bei geöffneter .accdb wird der Assistent ausgeblendet!!!

 

Problem gelöst dank Dir, Anne, Du bist die Beste *wink.gif* *wink.gif*

Dein Code hat fuktioniert.
Ich musste lediglich in den Verweisen was umstellen: Es existierte noch ein Verweis OLE-Automation, den habe ich abgemeldet (wieso der überhaupt an war, weiß ich nicht). Danach lief Dein Code rund.
Nochmals vielen Dank an Anne.
Thread kann geschlossen werden; aber weitere Anmerkungen sind hier gern willkommen.

 

Ja, aber was ist so schlimm daran?

PS:
Egal welcher "Schutz" implementiert wird, wenn ich global in Access das Ausführen von VBA-Code verbiete, funkionieren diese alle nicht mehr und ich kann meine gewünschten Einstellungen vornehmen.

Das Gleiche gilt für den Import/Export von Elementen.

 

stendate,

Sorry, aber damit weiß ich jetzt so nichts anzufangen?!
Ausführen von (von mir selbst eingebautem) VBA-Code soll ja nicht verboten sein.

 

An alle,
ich vergaß:

Aus dem ganzen wird ja erst ein Schuh, wenn man dann natürlich doch noch die Shft-Taste blockiert, wie es Don Karls 1.8 aufzeigt. Das funzt auch noch in Access 2010.
Erst danach ist es nicht mehr möglich, mit festgehaltener Shft-Taste doch noch im Backstagebereich zu den Optionen zu gelangen und den Navigationsbereich wieder zu aktivieren.
Vorsicht: Wer hier was ausprobieren möchte, sollte an die Hintertür denken *wink.gif*