PDA

Vollständige Version anzeigen : Importieren bei Dateien mit PW-geschütztem Code


micmen
25.01.2008, 17:08
Hi,
ich kann mir zwar nicht denken, daß ich der erste bin, der das fragt, aber ich habe zu dem Thema nix gefunden (nur was ähnliches zu gesetztem Datenbank-, nicht Code-Paßwort):
Wir verwenden grundsätzlich den Paßwortschutz für Projekte (Modulcode), seit Module nicht mehr wie alle anderen Objekte auch über die Benutzer- und Gruppen-Berechtigungen geschützt werden können. Dadurch ergibt sich ein überaus lästiges Problem bei der Zusammenarbeit mehrerer Personen:
Wenn einer an einem Formular, Bericht oder Modul gearbeitet hat und jemand anderes das Objekt importieren will, kommt diese Meldung:Microsoft hilft beim Schützen dieses VBA-Projekts mit einem Kennwort. Um diese Operation auszuführen, müssen Sie zuerst im Visual-Basic-Editor das Kennwort eingeben.Es hat aber die ganzen Jahre noch keiner von uns je geschafft, das zu tun...
Egal, in welcher Datei (Quelle oder Ziel) man das Codefenster öffnet und mit dem Paßwort entsperrt, keiner ist je weitergekommen. Wir alle gehen jedesmal zähneknirschend und mühselig den Weg, erst die Quelldatei zu öffnen, dann aus ihr das Kennwort zu entfernen, dann aus der Zieldatei heraus die Objekte zu importieren und dann in der Quelldatei wieder das Kennwort zu setzen. Und mehrfach ist es schon passiert, daß jemand vergessen hat, das Kennwort wieder zu setzen, und dann lagen da ungeschützte Dateien herum.

Ist das ein hartnäckiger, seit mehren Jahren jedes SP überdauernder Microsoft-Bug oder stimmt es wirklich, was da ausgegeben wird: Daß man lediglich irgendwo das Kennwort eingeben (nicht zurücksetzen...) muß?


Danke!

Louisleon
25.01.2008, 22:49
Hallo,

leider verlief der Versuch nicht so erfolgreich wie ich erst angenommen habe.
Die Frage stellt sich aber wieso zwei DB's mit VBA-Schutz versehen sind.
Wenn in der Regel nur die Produktiv-Version PW-Schutz hat, besteht die Möglichkeit einen Import in diese Version zu machen.
Das erspart zumindest das löschen des VB-PW auf der Produktivvariante ;)
Und in der Entwicklerversion ist ein VB-PW eh mehr hinderlich als nützlich.


Gruß

LL

micmen
25.01.2008, 23:34
Die Frage stellt sich aber wieso zwei DB's mit VBA-Schutz versehen sind.Hi,
die Versionen, die übergeben werden, liegen halt immer irgendwo auf Sticks und externen Laufwerken oder in mails rum. Die brauchen im Prinzip noch eher einen Schutz als die "wohlgehüteten" Entwicklungsversionen, die jeder bei sich hat...

Anne Berg
26.01.2008, 00:58
Dumme Frage: Vor wem willst du eigentlich den Code schützen? :confused:


Ich setze dabei voraus, dass das Erscheinen des Datenbankfenster sowie jeglicher Zugang zu Entwurfsansichten gesperrt ist. Der Benutzer wird über Formulare durch die Anwendung geführt - wieso sollte er hinter die Kulissen schauen wollen? Er will doch mit deinem Programm arbeiten, oder nicht?

micmen
26.01.2008, 02:51
Die engagieren sogar Softwarefirmen, die unsere Access-Anwendung Fenster (=Formular) für Fenster kopieren sollen. Wenn die noch an den Code kämen...

Anne Berg
26.01.2008, 22:44
Hallo, warum setzt du denn dann keine MDEs ein?

Josef P.
26.01.2008, 23:11
Die engagieren sogar Softwarefirmen, die unsere Access-Anwendung Fenster (=Formular) für Fenster kopieren sollen. Wenn die noch an den Code kämen...
Die engagieren dann aber "Softwarefirmen :entsetzt:" mit wenig Kreativität, wenn sie nicht an den Code einer mdb kommen. :D

micmen
31.01.2008, 14:12
Hallo,
kurze Pause, sorry.

Die herausgegebenen Versionen sind immer MDEs. Aber wie Ihr Euch denken könnt, im- und exportieren wir Objekte, die über ein VB-Kennwort geschützt sind, kaum in/aus MDEs... ;)
Also - ist klar, daß das nie MDEs sein können?

Die Leute dieser Firma haben sie natürlich auf unsere MDE-Anwendung angesetzt. Und wie kreativ die sind oder nicht hat mich bis jetzt nie interessiert...

Wir wollen auf keinen Fall das Risiko eingehen und unsere MDBs mit den auszutauschenden Objekten ungeschützt herumliegen haben. Und das Problem sind wohl die Dateien, aus denen importiert wird, und nicht die, in die importiert wird: Wir müßten also jedesmal, wenn wir an eine der Dateien heranmüssen, diese erst einmal öffnen und den Schutz entfernen. Und nach jedem Import muß man daran denken, die Datei wieder neu zu schützen.

A) ist das alles sehr umständlich und B) heißt es in der MS-Meldung nicht, man müsse den Schutz entfernen, sondern man müsse das Kennwort eingeben. Eine umständliche, zeitraubende und gefährliche Behelfslösung habe ich ja - ich suche also nicht irgendeine Möglichkeit, überhaupt arbeiten zu können. Sondern was mich interessiert ist, wie die von MS sich das Vorgehen gedacht haben und ob das wahr ist, was in der Meldung steht, daß man lediglich das Kennwort an der richtigen Stelle eingeben muß (oder ob es sich um einen seit vielen Jahren unverändert bestehenden Bug handelt).


danke!

Josef P.
31.01.2008, 18:40
Wir wollen auf keinen Fall das Risiko eingehen und unsere MDBs mit den auszutauschenden Objekten ungeschützt herumliegen haben.
Folgendes ist vermutlich nihht das was du hören willst, aber ich schreibe es trotzdem. ;)

Eine mdb kannst du nicht ausreichen schützen.
Es lohnt sich meiner Ansicht nach nicht, über etwas nachzudenken, was innerhalb einer Minute entfernt ist.

Eine Variante fällt mir bezüglich Code ein: wie bei .net-Programmierung, den Code so verunstalten, dass er nicht mehr lesbar ist. Damit ist er zwar immer noch lauffähig, aber er kann zumindest nicht mehr so einfach benutzt werden.

micmen
07.02.2008, 17:42
Folgendes ist vermutlich nihht das was du hören willstrichtig! :)

Nein, Scherz beiseite.
Ich sage nicht, daß die hier - sagen wir "zusätzlich" - gegebenen Ratschläge nicht hilfreich wären, aber eigentlich geht es in dem Thread ja um eine konkrete Sache, und ich würde ganz gerne in einem eleganten Bogen nochmal darauf zurückkommen:

Weiß jemand, ob das nun ein jahrealter MS-Bug ist, oder ob es tatsächlich möglich ist, so vorzugehen, wie in der MS-Meldung angegeben?

danke wieder :)