Registry: Open Key liefert False, warum?

[MrSpock]

Hallo,

mit dem nachfolgenden Code greife ich auf die Registry zu und lese den ODBC Eintrag aus für den Zugriff auf die KHK New CL.

Das Programm liegt auf dem Netz und mehrere Mitarbeiter haben Zugriff darauf.

An einer Station wird in die Debug-Datei die Ausgabe:

Zitat:

Key:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\O DBC.INI\Post51 nicht gefunden

geschrieben. D.h. dass die OpenKey Funktion nicht erfolgreich durchgeführt wird.

An dieser Station lässt sich RegEdt32 starten und der Key anzeigen, der genau an der angezeigten Stelle steht.
Der Benutzer hat Administrator Rechte.

Woran kann es liegen, dass OpenKey nicht den gewünschten Key öffnet?

Delphi-Quellcode:

try
      AssignFile(DebugTxt, ExtractFilePath(Application.ExeName)+'\Debug.txt');
      Rewrite(DebugTxt);
      Reg := TRegistry.Create;
      Reg.RootKey := HKEY_LOCAL_MACHINE;
      if Reg.OpenKey('\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\Post51', False) then
      begin
         station := Reg.ReadString('DBQ');
         Writeln(DebugTxt, 'station='+station);
         Ini := TIniFile.Create(station);
         KHKDatenverzeichnis := Ini.ReadString('Directories', 'DatPath', 'C:\');
         Writeln(DebugTxt, 'KHKDatenVerzeichnis:'+KHKDatenVerzeichnis);
         { In der CL 3.5 hat der Eintrag "Database" die Form " MxxxVyy"
           wobei xxx die Mandantennummer ist und yy das Finanzjahr.
           Achtung: Der Eintrag beginnt mit einem blank! }
         station := Reg.ReadString('DATABASE');
         Mandant := StrToInt(Copy(Reg.ReadString('DATABASE'), 3, 3));
         Writeln(DebugTxt, 'Mandant:'+IntToStr(Mandant));
         KHKMandantenVerzeichnis := KHKDatenVerzeichnis+IntToStr(Mandant);
         Writeln(DebugTxt, 'KHKMandantenVerzeichnis:'+KHKMandantenVerzeichnis);

         Ini.Free;
         user := Reg.ReadString('UID');
      end
      else
         Writeln(DebugTxt, 'Key: '+'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\Post51'
                           +' nicht gefunden');
      CloseFile(DebugTxt);
      Reg.CloseKey;
      Reg.Free;
   except

[Bummi]

Rechteproblem?

TRegistry.Create(KEY_READ);

[MrSpock]

Hallo Bummi,

super! Das hat funktioniert. Warum hat mein Code an manchen Stationen funktioniert und an anderen nicht?

Ein lokaler Admin muss doch immer gleich auf die Registry zugreifen können, oder?

[Bummi]

UAC Vista (+) ?

[himitsu]

Zitat:

Delphi-Quellcode:

+' nicht gefunden'

Und ich dachte du weißt was GetLastError/SysErrorMessage/RaiseLastOSError ist?

Zitat:

Der Benutzer hat Administrator Rechte.

Schön für den Benutzter.
Und welche Reschte besitzt das Programm?

Zitat:

Zitat von Bummi (Beitrag 1185180)

UAC Vista (+) ?

[MrSpock]

Das Programm liegt wie gesagt im Netzwerk. Auf mehreren Maschinen wird es über einen Link aufgerufen. Auf manchen Maschinen funktioniert der Aufruf von OpenKey mit dem default access Typ. Bei anderen nicht.

[Bummi]

wie sieht es bei "als Administrator ausführen" aus?

[himitsu]

Nur weil der Benutzer als Administrator arbeitet, sind nicht automatisch alle Programme mit Admin-rechten ausgestattet (dank UAC)
und in diesem Zweig hat nunmal zurecht nicht jeder einfach so Schreibrechte.

[MrSpock]

Zitat:

Zitat von himitsu (Beitrag 1185199)

Und ich dachte du weißt was GetLastError/SysErrorMessage/RaiseLastOSError ist?

SysErrorMessage(GetLastError) liefert übrigens:

Zitat:

Der Vorgang wurde erfolgreich beendet.

RaiseLastOSError liefert:

Zitat:

Ein Aufruf einer Betriebssystemfunktion ist fehgeschlagen.

[borncrush]

Hallo mrSpock, :-)

ich frage mal anders rum. Was ist denn letztendlich dein Ziel? Was willst Du auslesen?
Gibt es da keine anderen Wege?
Wir sind (zufälligerweise) ein Programmierer-Team gerade für Produkte von Sage (in- und externe Entwicklung). Ich bin speziell für die Classic Line bzw. heute Sage New Classic zuständig.

Wir arbeiten regelmäßig per ODBC Schnittstelle, nun gut heutzutage auch direkt per MySQL, und haben zu gut wie nie Probleme. Ist zwar ein wenig "mistig" der ODBC-Treiber, aber es geht schon.

Gruß

[MrSpock]

Hallo borncrush,

ich möchte über den ODBC Treiber die wesentlichen Informationen auslesen (Datenpfade, Mandant).
Das habe ich ja jetzt mit "KEY_READ" auch hinbekommen. In einer anderen Anwendung muss ich den ODBC Treiber aber dynamisch anpassen, da ich z.B. auf aktuelle oder auf Vorjahresfinanzdaten zugreifen muss. Diese Info steht ja im ODBC Treiber.

Interessant ist aber, dass ihr direkt über mySQL auf die Daten zugreift!? In der Dokumentation wird das als nicht möglich bezeichnet und man wird aufgefordert über ODBC auf die Daten zuzugreifen.

[borncrush]

Aloha kāua....

Ja, es ist technisch gesehen, kein Problem nativ auf die Daten zuzugreifen. Sage garantiert Dir bloß keine kosistenten Daten, wenn man sie selbst ausliest. Hintergrund sind die fehlenden Datenbankbeschreibungen, sowie dessen Logikzusammenhänge. Vor zwei Jahren (also noch zu ISAM-Datenbankzeiten) war es richtig schlimm. Aber egal.

Der ODBC Treiber von Sage ist imho schon ne Krücke. ABER: Er gewährleistet konsistente Daten beim Auslesen. Man muss wissen, dass das Programm nicht direkt auf den mySQL-Server schreibt, sondern noch ein in .NET-programmierter Interpreter dazwischen hängt. Der sorgt für weitere Datenlogiken, die nicht aus der mySQL-Schemenstruktur erkennkbar ist. Daraus resultiert, dass man möglichst NIE per mySQL nativ Daten -schreiben sollte-!!! Ohne weitere Kenntnisse rate ich davon also ab. Aber lesen ist ok, solange man die Zusammenhänge bei den Bewegungsdaten "verstanden" hat. Stammdaten sehe ich also unkritisch und nachvollziehbar ein.
Ein zusätzlicher Vorteil der ODBC-Variante ist, dass jegliche Datenbankänderungen (Feldänderungen etc.) berücksichtigt werden im Gegensatz zum nativen SQL-Zugriff. Da wir Developer-Partner bei Sage sind, bekommen wir Datenbankstrukturänderungen mitgeteilt.

Nochmal kurz zur Problemsituation:
Wenn Du per ODBC zugreifst, gibt es offiziell keine andere Variante den Jahrespräfix, Stations-INI, etc. zu ändern. Ich bin der Meinung, dass es hierfür aber "Steuerbefehle" gibt, die das doch möglich machen. Wenn ich etwas finde, hinterlasse ich hier einen Post :-). Und ich bin mir sehr sicher.

Was musst du genau ändern?
Mandantennummer und Jahrespräfix? Dann gibt es sicher ne Lösung.
Stationsdatei? Sieht schlecht aus.....

Happy Diving!
:cyclops: :-D

[MrSpock]

Im Moment ändere ich den Jahresprefix per Delphi-Programm direkt beim ODBC Treiber in der Registry. Anschließend greife ich über den modifitierten ODBC Treiber auf die New CL zu. Das funktioniert auch bisher. Falls es aber jetzt ein Zugriffsproblem auf den ODBC Treiber in der Registry gibt, werde ich die Berechtigung dort entsprechend anpassen.

Mein Ursprungsproblem war, dass bei einigen neuen Win7 64-Bit Clients das Öffnen des Registry Keys fehlgeschlagen ist. Mit KEY_READ beim Create hat es aber funktioniert.

In meinem zweiten Programm für denselben Kunden mache ich eine Kostenstellenauswertung. Dort kann der Kunde wählen, ob für das aktuelle, das Vorjahr oder das Vor-Vorjahr di Auswertung gemacht werden soll. Je nach Auswahl passe ich en ODBC Treiber an.

Bis vor 3 oder 4 Jahren habe ich noch über COM Objekte auf die CL zugegriffen. Das war aber immer ein Risiko, weil ich keine Beschreibung der Änderungen in den internen Strukturen hatte.

[borncrush]

Ohje...viel zu tun :(

Probier mal mit dem folgenden Syntax, den Jahrespräfix und die Mandantennummer zu übergeben. Dann brauchst Dur eine ODBC-Verbindung (auch ohne jegliche Anpassungen). Sollte also gehen:

Die Syntax lautet bei Tabellen ohne Platzhalter:

[Mandant_][Jahrespräfix_]Tabellenname[_Satzartenname]

Die Syntax lautet bei Tabellen mit Platzhalter:

[Mandant_][Jahrespräfix_]Tabellenname[_Satzartenname]__Platzhalter

Beispiel für Artikelpositionen in Aufträgen in Mandant 991, Jahr 0 (aktuelles Jahr, aber ist ja in der WaWi/auftragsbearbeitung eh egal, doch bei der FiBu eben nicht)
M991_V00_AuftraegePositionen_Artikel

Beispiel für Kassenbelege für Kassennr. 3 im aktuellen Mandanten, aktuelles Jahr
Kassenbelege__003


Gruß

[MrSpock]

Danke für den Hinweis, das werde ich einmal ausprobieren.