[IB/FB] Computername ermitteln

[Hansa]

Hi,

zuerst : es geht nicht darum, den Windows-Computernamen zu ermitteln ! Ich bräuchte den schon in der Datenbank und zwar innerhalb eines Triggers. Geht das irgendwie einfach ?

[mkinzler]

Es gibt m.W. nur die Kontextvariable CLIENT_ADDRESS, in der die IP-Adresse des Rechners steht. Reicht dir das, oder benötigst du den Netbios-Namen? Dann mußt du m.E. eine UDF schreiben, welche dir die Auflösung übernimmt.

[Hansa]

Das scheint aus gutem Grund wie geplant so wohl nicht möglich zu sein, also die DB selber den Computernamen ermitteln zu lassen. Client_Adress scheint auch unbekannt zu sein. U.a. Linux & Co. lassen grüßen. Das ist aber nicht weiter schlimm, denn ich kann ja den Computernamen vom Programm ermitteln lassen. Dabei stellt sich allerdings die Frage, wie ich diesen der DB letztenendes mitteile. Mir schwebt dazu eine Art globale Variable vor, die eben überall in der DB verwendet wird, also auch innerhalb der Trigger. Und da verließen sie ihn. Any ideas ? :mrgreen:

[mkinzler]

Möglicherweise ist die Kontextvariable Client_Adress auch erst ab FB 2 vorhanden.

Zitat:

Mir schwebt dazu eine Art globale Variable vor, die eben überall in der DB verwendet wird, also auch innerhalb der Trigger. Und da verließen sie ihn. Any ideas ? Mr. Green

Eigene Kotextvariablen sind leider auch erst ab der Version 2 vorhanden :-(

[marabu]

Ich habe meine UDF-Demo um die Funktion ComputerName() erweitert. Vielleicht hilft es.

Grüße vom marabu

[mkinzler]

Auf marabu ist Verlass! :thumb:

[Union]

@marabu: Du bist wohl ein kleiner Scherzkeks, oder ;) Die von Dir zur Verfügung gestellte Funktion gibt doch den Computernamen des Servers wieder. Das ist nur dann sinnvoll, wenn man FB embedded verwendet. Sobald Client/Server unterschiedlich sind hat das keinen tieferen Sinn mehr, da konstant. Oder habe ich Hansa da falsch verstanden?

[marabu]

Naja - halt ein verfrühter Aprilscherz...

Nachtrag: Ich würde die Zuordnung USERNAME zu COMPUTERNAME in einer speziellen Tabelle pflegen. Das hat den Vorteil, dass es persistent und unabhängig vom RDBMS ist. Nach dem Login kann der Satz für den User mit einer Stored Procedure und der internen Variable USER aktualisiert oder neu erstellt werden.

marabu

[mkinzler]

@hansa: Habs gerade mit der Version 1.5.3 auf Linux ausprobiert. Dort geht es leider auch nicht. :-(

Aber mit FB2 gehts es :-) Soll ja bald fertig sein.

SQL-Code:

select rdb$get_context( 'SYSTEM', 'CLIENT_ADDRESS') from rdb$database;

[Hansa]

Zitat:

Zitat von marabu

...und der internen Variable USER aktualisiert oder neu erstellt werden.

Es geht mittlerweile darum, diese "interne" Variable zu setzen und auch weiter zu benutzen. Da nützt mir auch eigene Table nichts. UDFs wurden bisher nicht benötigt, aber irgendwie sagt mir mein Gespür, daß in dieser Richtung was gehen könnte. :gruebel: Es wird wohl irgendein Trick benötigt. 8)

[mschaefer]

Moin, Spätmoin,

also ein interesantes Thema habt Ihr! Die Windows-Computernamen sind allerdings nicht notwendigerweise eindeutig. Müßte es nicht letzlich die MAC-Adresse sein, die eingetragen werden soll?

Grüße in die DB-Runde // Martin


PS Was ist der Hintergrund? Soll jetz nur festgehalten werden, wer den Datensatz angelegt hat oder wer ihn im Bearbeitungsmenue stehen hat (aktuell gesperrt)?

[Hansa]

Moin Martin,

MAC-Adresse ändert ja nichts am Problem. Der Datenbank muß mitgeteilt werden, wer ein Insert/Update gemacht hat. Kann natürlich jetzt nur für mich sprechen : jede Tabelle hat ein Feld "angelegt" und "LetzteAenderung". Das verwalten die Trigger automatisch. Hierbei habe ich überlegt, wenn schon dann gleich den Computernamen auch noch mitzuschleppen. Am besten wäre es IMHO mit einer Zeile mehr in den Triggern. Inwieweit man das ausdehnt ist eine andere Sache. Z.B. könnte man ALLE Änderungen chronologisch in Hilfstabellen abspeichern, sofern jemand das Handwerk zu legen ist ! 8) Ohne Computername wäre so was aber nur schwer zu lokalisieren. Nächster Einsatzzweck wären DAUs, die selbstverständlich keinen Unfug treiben. Auch um eigene Fehler im Programm zu finden kann so was im Zweifelsfall helfen.

[mkinzler]

Moin Hansa,

du könntest auch eine Login-Tabelle anlegen, an der sich das Programm im AfterOpen der Connection anmeldet und hier den eigenen Computername/MAC-Adresse o.ä. mitteilt. Durch einen Trigger könntest du diesem Computernamen die Connection_id der DB zuordnen (Kontext CURRENT_CONNECTION).
In den Triggern der anderen Tabellen könntest du dann durch Trgger den Computernamen übernehmen. Diese Lösung ist zwar nicht ganz sauber, könnte aber funktionieren.

[Jelly]

Wie wird denn in die DB eingeloggt. Hat da jeder User ein in Firebird definiertes Konto... Damit kannst du sicherlich auf Serverseite was anfangen, indem du jeweils diesen Firebirdusernamen in deine Tabellen schreibts (bzw. einen Verweis)

[raiguen]

Moin :-))

Wenn ich mal folgende Überlegung(en) einwerfen darf:
laut hansa geht es ja darum, welcher hochintelligente User einen Datensatz in der DB angelegt bzw verändert hat. Da nützt der Comuptername als solches wenig, weil damit ja noch nicht eindeutig klar ist, welcher User am Computer arbeitet und Modifikationen in der DB vornimmt.

Es gibt da zwei schöne Funktionen:
1. WNetGetUser --> gibt den Namen des im Netzwerk angemeldeten Users,sofern im selbigen eingeloggt; ansonsten den Benutzernamen am Computer.
2. GetUserName --> gibt den Namen des aktuell am Computer bzw im Windows angemeldeten BEnutzers.

Zur eindeutigen Identifizierung des Benutzers, welcher da was in der DB gemacht hat, müssten dann alle drei Informationen ComputerName,UserName,NetzLoginName - z.b. zusammengefasst in einem String - abgespeichert werden...

Delphi-Quellcode:

function NetzLoginName: String;
var
  size: Cardinal;
begin
  Size := 0;
  WNetGetUser(nil,nil,size);
  SetLength(RESULT,Size);
  if WNetGetUser(nil,PChar(RESULT), Size) > 0
    then  Result := '';
end;

function ComputerName: PChar; //--Code vom marabu
var
  buf: array [Byte]of Char;
  size: Cardinal;
begin
  size := SizeOf(buf);
  if GetComputerName(@buf, size)
    then Result := @buf[0]
    else Result := nil;
end;

function UserName: PChar;  //--o.a. Code vom marabu angepasst
var
  buf: array [Byte] of Char;
  size: Cardinal;
begin
  size := SizeOf(buf);
  if GetUserName(@buf, size)
    then Result := @buf[0]
    else Result := nil;
end;

Ich denke, dass diese Informationen wahrscheiblich nicht über einen Trigger in der DB erhältlich sind, aber mit Sicherheit im OnCreate der Hauptform...

[Jelly]

Zitat:

Zitat von raiguen

Ich denke, dass diese Informationen wahrscheiblich nicht über einen Trigger in der DB erhältlich sind, aber mit Sicherheit im OnCreate der Hauptform...

Ich denke aber, dass es eben genau darum geht, diese Informationen im Trigger zu lösen, da es mit deiner Methode nur mit deinem Programm funktioniert, nicht aber wenn über ein DB Tool an den Daten rumgefuscht wird.

[mschaefer]

Also Ihr habt da beide irgendwie recht, :zwinker:
denn einerseits hat Hansa auf den DAU :mrgreen: verwiesen andererseits auf den Trigger :stupid: .


THEMA: Rechnerkennung
Ok die IP-Eintragen geht wohl ohne Probleme im Trigger. Ob man jetzt per UDF noch weiteree Daten Computername MAC-Adresse einfügen sollte, da bin ich der Auffassung: Lasst es! Genau in dem Moment, wo LAN-Verkehr durch das DBMS da ist, fängt plötlich eine UDF an Netzwerkabfragen durchzuführen. Da ist der Ansatz das per eigenem Programm gleich mitzusenden irgendwie Netzwerksparender und was den Nutzer angeht auch Informativer. Tja ob beide Ansätze zu kombinieren sind...


THEMA: Eingabestatus
In dem Zusammenhang habe ich meistens das Problem, dass ein Rechner in der Eingabemaske steht und dann sollte bei den anderen Rechnern in der ÜBersichtsliste markiert sein, dass dieser Datensatz bearbeitet wird. Sowas scheint mir am besten hier in einem Aufwasch mit zu erledigen zu sein.


THEAM: Versionsrekonsturktion
Das Rückgängigmachen oder das Speichern von alten Eingabeständen kann eigentlich sinnig nur im DBMS gelöst werden, denn bei jedem Update oder Insert müßte der Datensatz mit Zeitstemple in einer Backuptabelle gespeichert werden. Das habe ich bisher mit FB noch nirgends gesehen (könnte natürlich trotzdem gehen).


Grüße in die DB-Profi-Runde // Martin

[Hansa]

Jetzt mal langsam. Es geht hauptsächlich um das Prinzip, wie so etwas am Besten zu machen ist. Vom Programm aus irgendein Tabellen-Feld zu setzen ist kein Problem. Den Computernamen usw. auszulesen auch nicht. Natürlich kann ich das von Hand bzw. vom Programm aus erledigen. Wenns keiner verstehen soll, sagt man besser "der Client" soll das machen. :mrgreen: Soweit so gut. Wie manipuliere ich nun Datenbestände ? 1. DB-Tool : wenn man sieht, daß sogar hier einige nicht wissen was das ist, dann kann man das außen vor lassen. 2. Programm (könnte auch fremdgeschriebenes sein !) : noch unwahrscheinlicher. 3. das eigene Programm, so wie es auch vorgesehen ist wird bewußt zweckentfremdet/falsch bedient.

Nun speichere ich im Programm normalerweise per SP. An einigen Stellen allerdings auch mit Post etc. An all diesen Stellen müßte man Hand anlegen. Sollte das nötig werden, dann wäre ausnahmsweise eine globale Variable wohl am besten : beim Programmstart alles nötige ermitteln und damit später die Felder besetzen, ohne daß jedesmal alles neu deklariert / ermittelt werden muß, Parameter und blabla. Keine Frage, daß das so geht. Wenn schon, dann aber nicht im FormCreate, sondern im DataModuleCreate. Meine Idee war ja, daß das im Trigger gemacht werden soll, also egal wie ein insert/update zustande kommt.

Dann noch Marabus Vorschlag. Dank diesem war ein kurzer Exkurs zu den UDFs nötig. Union hats ja direkt gesehen : geht so nicht. Ich habe es durchexerziert, allerdings einfach mit GetComputerName. Die UDF ermittelt einwandfrei den Computernamen und speichert ihn auch per Trigger automatisch ab. Allerdings von dem Computer, auf dem die DB und somit die UDF liegt, also vom Server. 8) Dann noch ClientAdress. FB 2 Beta ? Hmm, etwas zu früh. Allerdings habe ich gesehen, daß es da SetConText??? und GetContext??? gibt. Eventuell wäre das genau das Gesuchte. Werde deshalb eventuell 2 vorläufuge Dummy-Felder Computername und Username in alle Tabellen einbauen.

Zur Problematik an sich : es geht um diverse Sachen, konkret tatsächlich um einen 3/4 Computer-DAU, der Fehler nie zugibt und einen Normaluser. Beide sind allerdings in puncto Geld/Lager absolut nicht als DAUs zu bezeichnen. 8)

[Jelly]

Zitat:

Zitat von Hansa

1. DB-Tool : wenn man sieht, daß sogar hier einige nicht wissen was das ist, dann kann man das außen vor lassen. 2. Programm (könnte auch fremdgeschriebenes sein !) : noch unwahrscheinlicher. 3. das eigene Programm, so wie es auch vorgesehen ist wird bewußt zweckentfremdet/falsch bedient.

Daraus les ich, dass Punkt 3 Dich betrifft. Somit kannst Du also das Ganze am Client lösen, oder ?

[Hansa]

Jelly, das geht natürlich. Ist aber nicht das Thema. Deshalb steht es auch bei Datenbanken. Es geht nicht alleine nur um "Computername ermitteln". Es geht darum, diese Funktionalität direkt in der DB zu haben. Meinen "Fall" habe ich zwar im Griff, aber schön wäre es, das zu verallgemeinern und unabhängig vom Programm zu machen. Vielleicht gehts ja auch ganz anders ? Datenbanken zeichnen sich manchmal dadurch aus, daß vermeintlich "Unmögliches" mit einem ganz simplen Trick gemacht werden kann, auf den man selber gar nicht kommt.

[mschaefer]

Moin zusammen,

mir kommt da gerade so eine Idee. Wäre es nicht am günstigstem ein geteiltes Verfahren. Die UDF kann sicherlich auch den Computernamen anderer Computer im Netz ermitteln. Da hat marabu eben erst mal den Anfang gemacht und da word sich mehr realisieren lassen. Angaben über den aktuellen Nutzer am Programm kann natürlich nur das Programm machen. Wenn das aber eine Socket-Componetne hat, die von der UDF aus Daten abfragt, dann könnte die UDF mehr Information bekommen. So hätten wir zwei Fälle. !. Das eigene Programm liefert die Gesamtinfo oder ein anderes Programm liefert keine Info, IP und Computername sind aber eingetragen.

Grüße // Martin

[mkinzler]

Da eine UDF eine normale Dll ist, kann man alles mögliche mit ihr machen. Da sie aber mit dem Starten einer DB mit geladen wird, belegt sie dann auch Speicher. Problematisch könnte auch das Erzeugen von weiteren Netzverkehr der Dll und die Laufzeit der UDF sein.

[marabu]

Hi folks.

Die UDF zur Ermittlung des Namens der client workstation ist doch nur eine Krücke. Das Hauptproblem ist, dass FireBird die Information über den Client besitzt, aber erst ab Version 2 exportiert. Wer sich über NETBEUI mit dem Server verbindet, der gibt seinen Maschinennamen bekannt, und wer sich über TCP/IP verbindet, der übermittelt seine IP-Adresse.

Ich hatte in Beitrag #8 eine anwendungsübergreifende Tabelle (vergleiche mit dem Vorschlag von Markus in Beitrag #13) vorgeschlagen und habe in der Zwischenzeit noch einen Ansatz über eine Stored Procedure erfolgreich getestet, aber da Hansa ja nach einer Lösung sucht, die sich nicht auf Client-Code, sondern einzig und alleine auf Server-Code abstützt, ist das Thema ja eigentlich schon längst totdiskutiert. Ohne Eingriff in die Server-Quellen wird es wohl erst ab FB2 gehen.

Unabhängig von irgenwelchen Machbarkeitsüberlegungen zweifle ich den Nutzen eines mitgeführten Maschinennamens an. Die Zugriffskontrolle in Datenbanken wird nunmal über die Authentisierung der Benutzer ausgeübt. Wenn meine Kollegen vom Betrieb mehr wollen, dann können sie (wie auch schon in SNA-Netzen) den Zugriff nur bestimmten Workstations gestatten, Portwächter installieren, Log-Files auswerten, und vieles mehr. Alle diese Aktivitäten finden aber völlig getrennt von der Anwendung auf einer anderen Ebene statt. Schon das sichtbare Speichern eines timestamp nebst username direkt in einer Basistabelle der Anwendung durchbricht streng genommen dieses Prinzip (information hiding in Datenbanken).

Freundliche Grüße vom marabu