|
| |
VB & Datenbanken| VirtualStore | |  | | Autor: erich1961 | | Datum: 06.11.15 11:09 |
| Hallo Leute,
ich habe ein VB6-DAO-Datenbank-Anwendung, die auch unter > Vista läuft. Die Anwendung läuft im Programmverzeichnis, Datenbank unter Laufwerk\Programdata\$Verz\Mandant_x\Daten\Access-Datenbank, das Verzeichnis ist aber einstellbar. Keine system.mdb. Funktioniert. Habe nun einen neuen Rechner mit W7prof 32bit ausgestattet, Software mit eigenem Setup installiert. Software und Datenbank werden von kleinem Programmen upgedatet, die vom Hauptprogramm aufgerufen werden. In der Db existiert eine Tabelle, wo der Revisionsstand festgehalten wird und von den Programmen dann kontrolliert wird und wenn es notwendig ist, wird das Datenbankupdate angestossen und die DB-Update-Soft wird aufgerufen.
Nun spielt sich das so ab, dass das Hauptprogramm beim Start die Revision 71 erkennt, es wird vom DB-Programm nach dem Tabellen-Update Version 72 eingetragen. Beim nächsten Neustart das gleiche. 71 und 72. Die Routinen sind die Gleichen zur Abfrage der RevisionNummer. Täglich grüßt das Murmeltier.
Am nächsten Tag habe ich dann mal den Prozessmonitor von Sysinternals befragt und siehe da: das Hauptprogramm wird reparsed auf den VirtualStore. Ich weiß, dass ich dieses Verhalten mit einer Richtlinie gegebenfalls abschalten kann. Ich könnte auch beide Programme wieder zusammenführen, aber gibt nunmal gute Gründe dies getrennt zu halten. Das Programm- & Datenbankupdate ist mit einer Manifestdatei ausgestattet.
Was kann ich tun? Das mit der Richtlinie gefällt mir nicht wirklich. Das Hauptprogramm startet nicht als Administrator, sowas ist auch schwer zu vermitteln für die Anwender. Ich habe bestimmt was übersehen. | |
| Verschiedene Versuche & Lösungsmöglichkeiten | | | | Autor: erich1961 | | Datum: 09.11.15 09:58 |
| Ich habe verschiedene Sachen ausprobiert mit mehr oder weniger Erfolg:
Die Richtlinienänderung "Datei- und Registrierungsschreibfehler an Einzelbenutzerstandorte virtualisieren" hat nichts gebracht. Das habe ich auch wieder rückgängig gemacht.
Dann habe ich für mein Verzeichnis inkl. Unterverzeichnissen den Besitzer von Administrator auf Benutzer geändert, die Rechte auf Vollzugriff gesetzt, war aber auch nichts.
Einen kleinen Erfolg konnte dadurch erzielen, dass ich meine Verzeichnisstruktur von Programdata auf $laufwerk\Benutzer\$User\Local umgelegt habe. Das hat dann erstmal funktioniert. 72 und 72! Ist aber nicht im Sinne des Erfinders. Ich will die Sachen in Programdata haben.
Dann habe ich mit den Manifestdateien rumexperimentiert und auch mich auch ein klein wenig eingelesen. In den Manifestdateien kann man nicht nur festlegen, dass die Software adminstrative Rechte benötigt -> "requireAdministrator", sondern u.a. auch als Benutzer laufen lassen kann -> "AsInvoker". Letzteres habe ich dann für mein Hauptprogramm eingerichtet. War aber auch nicht vom Erfolg gekrönt.
Dann habe ich mein Hauptprogramm und den Manifestpedanten umbenannt. Von $Name & " proplus" auf $Name & "proplus". Das hat funktioniert. Scheidet aber als Lösung auch aus, ich ändere ohne weiteres keine kompletten Infrastrukturen. Mit zurückbenennen der Dateien kamen auch meine alten Probleme zurück.
Manifestcache hat wohl mit dem Problem zu tun, da waren aber auch keine Lösungen in Sicht.
Dann habe ich gelesen, dass, wenn die Dateien im Virtualstore vorhanden sind, diese auch preferiert werden.
Daraufhin habe ich ich Dateien bzw. das Verzeichnis, was dort im Virtualstore angelegt war, gelöscht.
Heureka! Das wars!
Ich füge allerdings hinzu, dass die Daten im Datenbanksystem ein eingespieltes Backup war. Ich kann auch nicht sagen, ob meine vorherigen Maßnahmen zur Lösung beigetragen haben. Das werde ich wohl mit dem nächsten einzurichtenden Rechner herausfinden. Und jetzt schlage ich mich mit RDX-Laufwerken rum.
mfG | |
| Re: Verschiedene Versuche & Lösungsmöglichkeiten | | | | Autor: Franki | | Datum: 18.11.15 08:31 |
| Hallo,
egal wie du das drehst und wendest, du wirst früher oder später nicht darum herum kommen dich an die "neuen" Richtlinien von Windows zu halten, dass solche Dateien nicht mehr in das Programmverzeichnis gehören.
Egal was du jetzt versuchst, das doch irgenwie hin zu bekommen wird wahrscheinlich irgendwann nicht mehr funktionieren, schon gar nicht wenn du an den Rechten des Users etwas ändern möchtest. Noch geht das mit Tricks, aber wie lange noch?
Alles was du bei dir mit Änderung der Rechte probiert hast, kann ein Kunde ja sowieso unter Umständen gar nicht machen weil er eben keine Berechtigung hat irgendwelche Rechte ändern zu können.
Mit der Manifest Datei bist du schon auf dem richtigen Weg, aber versuche doch nicht diese dazu zu missbrauchen, dass die Rechte umgangen werden. Wenn Administrator Rechte erforderlich sind, dann gib dem User den UAC Dialog wo er sich als Administrator legitimieren kann. Kann er das ist es gut, kann er das nicht geht es halt nicht weiter.
Das ist inzwischen gängige Praxis, die User (und Admins) haben sich inzwischen daran gewöhnt. Und wenn du begründest warum dein Programm für bestimmte Situationen Admin Rechte benötigt (Updates z.B.) nimmt es dir auch kein User übel sich über die UAC als Administrator zu identifizieren. Wenn er das bei deinem Programm nicht kann läuft etwas anderes schief.
Gruß
Frank | |
| Re: Verschiedene Versuche & Lösungsmöglichkeiten | | | | Autor: erich1961 | | Datum: 18.11.15 09:14 |
| Guten Morgen Frank,
es ging um die Datenbank, die in den VirtualStore geswitcht wurde und die liegt nicht im Programmverzeichnis, sondern wie beschrieben im Programdata-Verzeichnis. Das ist das Verzeichnis, wo imho Daten abgelegt werden sollen.
Ich habe auch schon einen Verdacht, wie das passieren konnte. Meine Setup-Routine schreibt mit Administrationsrechten im Programmverzeichnis meine Programmdateien und mit den gleichen Rechten im Programdata-Verzeichnis die Daten- und Verzeichnisstrukturen für DB, Error-,Login- und Updateprotokolle, Downloadverzeichnis, etc. Das gilt es, bei der nächsten Installation zu prüfen.
Ansonsten fang ich einfach im normalen Programm die Existenz der Datenbank im VirtualStore ab und lösch den Käse. Geändert habe ich, dass meine Datenbank-Update-Routine nun als Invoker läuft.
Freundliche Grüße
Erich | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
vb@rchiv CD Vol.6 vb@rchiv  Vol.6
Geballtes Wissen aus mehr als 8 Jahren vb@rchiv!
Online-Update-Funktion
Entwickler-Vollversionen
u.v.m.Jetzt zugreifen Tipp des Monats sevGraph (VB/VBA) 
Grafische Auswertungen
Präsentieren Sie Ihre Daten mit wenig Aufwand in grafischer Form. sevGraph unterstützt hierbei Balken-, Linien- und Stapel-Diagramme (Stacked Bars), sowie 2D- und 3D-Tortendiagramme und arbeitet vollständig datenbankunabhängig! Weitere Infos
|
Mai 2024
Sie sind aktuell nicht angemeldet.