+49 (0)7531 906010| service@combit.net

per vbscript die Systemzeit eines Servers auslesen

Hallo zusammen,

ich möchte per vbscript, welches auf einem Arbeitsplatzrechner ausgeführt wird, die Systemzeit eines Servers im Netzwerk auslesen, um zu erreichen, dass jeder, der das Skript von seinem Arbeitsplatz ausführt, mit der gleichen Systemzeit arbeitet.

Wie lautet die Syntax?

Gruß Marco

Hi Marco,

ich möchte per vbscript, welches auf einem Arbeitsplatzrechner ausgeführt wird, die Systemzeit eines Servers im Netzwerk auslesen, um zu erreichen, dass jeder, der das Skript von seinem Arbeitsplatz ausführt, mit der gleichen Systemzeit arbeitet.

Vorschläge:

1.) cRM > Konfig > Allgemein > ‚Beim Start die Uhrzeit des
Datenbankservers übernehmen‘ (oder setz entsprechend den Registrykey
„SyncClientTime“ auf 1 im Zweig HKEY_CURRENT_USER\Software\combit\combit
Relationship Manager\Settings) ->Nachteil: eingeschränkte Windows
Benutzer haben i.d.R. nicht das Recht die eigene System-Uhrzeit
anzupassen - lässt sich aber sicherlich über Gruppenrichtlinien einstellen.

2.) Falls die Uhrzeit „bloß“ in einem Feld landen soll, könntest du das
Feld einfach vom Typ „Erfassunngsdatum“ definieeren, dann kümmert sich
der cRM drum (er benutzt auch die Datenbankserver-Uhrzeit)

3.) geh per ADO auf den Datenbankserver und mach ein „select
CURRENT_TIMESTAMP“

4.) schreib eine BAT die den Befehl "net time " enthält (kann
man auch unter dem Systemaccount in der Autostart Gruppe laufen lassen,
damit umgeht man den oben unter 1. erwähnten Nachteil

5.) google mal nach VBScript und NTP bzw. SNTP.

HTH

Alex.


CRM-Leitsatz: „Das einzige, was wirklich stört, ist der Kunde!“ :wink:

Hi Alex,

danke für die schnelle Antwort. Ich habe noch ein paar Anmerkungen zu deinen Vorschlägen gemacht.

Hi Marco,

ich möchte per vbscript, welches auf einem Arbeitsplatzrechner ausgeführt wird, die Systemzeit eines Servers im Netzwerk auslesen, um zu erreichen, dass jeder, der das Skript von seinem Arbeitsplatz ausführt, mit der gleichen Systemzeit arbeitet.

Vorschläge:

1.) cRM > Konfig > Allgemein > ‚Beim Start die Uhrzeit des
Datenbankservers übernehmen‘ (oder setz entsprechend den Registrykey
„SyncClientTime“ auf 1 im Zweig HKEY_CURRENT_USER\Software\combit\combit
Relationship Manager\Settings) ->Nachteil: eingeschränkte Windows
Benutzer haben i.d.R. nicht das Recht die eigene System-Uhrzeit
anzupassen - lässt sich aber sicherlich über Gruppenrichtlinien einstellen.

Das hilft mir zwar beim Systemstart, aber wenn der User nach dem Start die Systemzeit verändert, dann habe ich das gleiche Problem wieder.

2.) Falls die Uhrzeit „bloß“ in einem Feld landen soll, könntest du das
Feld einfach vom Typ „Erfassunngsdatum“ definieeren, dann kümmert sich
der cRM drum (er benutzt auch die Datenbankserver-Uhrzeit)

Leider nicht.

3.) geh per ADO auf den Datenbankserver und mach ein „select
CURRENT_TIMESTAMP“

Mit ADO hatte ich es auch schon probiert, aber das Problem ist dann, dass ich bei jedem cRM-Client, der dieses Skript ausführt, ne ODBC-Verbindung einrichten muss. Oder geht das auch ohne? Hier mein Code:

set db = createobject („ADODB.connection“)
dim liste
db.open „test“,"","" '–> test ist der Name der ODBC-Verbindung
sql = „select getdate() as Uhrzeit“
set rs = db.Execute(sql)
liste = rs(„Uhrzeit“)
msgbox liste
db.close

4.) schreib eine BAT die den Befehl "net time " enthält (kann
man auch unter dem Systemaccount in der Autostart Gruppe laufen lassen,
damit umgeht man den oben unter 1. erwähnten Nachteil

5.) google mal nach VBScript und NTP bzw. SNTP.

HTH

Alex.


CRM-Leitsatz: „Das einzige, was wirklich stört, ist der Kunde!“ :wink:

Hallo Marco,

klar geht das:

set db = createobject („ADODB.connection“)
strCS = „Driver={SQL Server}; Server=datenbankserver; Database=combit_cRM_Solution2_DE; UID=sa; PWD=password“
db.ConnectionString = strCS
db.Open
sql = „select getdate() as Uhrzeit“
set rs = db.Execute(sql)
liste = rs(„Uhrzeit“)
msgbox liste
db.close

Gruss Micha

Hi Alex,

danke für die schnelle Antwort. Ich habe noch ein paar Anmerkungen zu deinen Vorschlägen gemacht.

Hi Marco,

ich möchte per vbscript, welches auf einem Arbeitsplatzrechner ausgeführt wird, die Systemzeit eines Servers im Netzwerk auslesen, um zu erreichen, dass jeder, der das Skript von seinem Arbeitsplatz ausführt, mit der gleichen Systemzeit arbeitet.

Vorschläge:

1.) cRM > Konfig > Allgemein > ‚Beim Start die Uhrzeit des
Datenbankservers übernehmen‘ (oder setz entsprechend den Registrykey
„SyncClientTime“ auf 1 im Zweig HKEY_CURRENT_USER\Software\combit\combit
Relationship Manager\Settings) ->Nachteil: eingeschränkte Windows
Benutzer haben i.d.R. nicht das Recht die eigene System-Uhrzeit
anzupassen - lässt sich aber sicherlich über Gruppenrichtlinien einstellen.

Das hilft mir zwar beim Systemstart, aber wenn der User nach dem Start die Systemzeit verändert, dann habe ich das gleiche Problem wieder.

2.) Falls die Uhrzeit „bloß“ in einem Feld landen soll, könntest du das
Feld einfach vom Typ „Erfassunngsdatum“ definieeren, dann kümmert sich
der cRM drum (er benutzt auch die Datenbankserver-Uhrzeit)

Leider nicht.

3.) geh per ADO auf den Datenbankserver und mach ein „select
CURRENT_TIMESTAMP“

Mit ADO hatte ich es auch schon probiert, aber das Problem ist dann, dass ich bei jedem cRM-Client, der dieses Skript ausführt, ne ODBC-Verbindung einrichten muss. Oder geht das auch ohne? Hier mein Code:

set db = createobject („ADODB.connection“)
dim liste
db.open „test“,"","" '–> test ist der Name der ODBC-Verbindung
sql = „select getdate() as Uhrzeit“
set rs = db.Execute(sql)
liste = rs(„Uhrzeit“)
msgbox liste
db.close

4.) schreib eine BAT die den Befehl "net time " enthält (kann
man auch unter dem Systemaccount in der Autostart Gruppe laufen lassen,
damit umgeht man den oben unter 1. erwähnten Nachteil

5.) google mal nach VBScript und NTP bzw. SNTP.

HTH

Alex.


CRM-Leitsatz: „Das einzige, was wirklich stört, ist der Kunde!“ :wink:

Hi,

Das hilft mir zwar beim Systemstart, aber wenn der User nach dem
Start die Systemzeit verändert, dann habe ich das gleiche Problem
wieder.

nur zur Sicherheit: das passiert bei jedem Start des cRM (und nicht des
Computers)

und bei allem Respekt: ist dein Einwand nicht etwas arg konstruiert? :slight_smile:
Dann hat der cRM (Erfassungsdatum) und die Terminverwaltung
(Erinnerungen) und vmtl. auch andere Anwendungen (z.B. eMail
Versendedatum) aber ein ganz andere „Herausforderungen“…

Anderenfalls nimm den Usern das Recht zum Ändern der Uhrzeit und nutze
Vorschlag Nummer 4. :wink:

Mit ADO hatte ich es auch schon probiert, aber das Problem ist dann,
dass ich bei jedem cRM-Client, der dieses Skript ausführt, ne
ODBC-Verbindung einrichten muss. Oder geht das auch ohne?

Das geht auch ohne, also rein zur Laufzeit. Beispiele findest du hier:
[url=http://www.connectionstrings.com

HTH,

Alex.

–][/url]
CRM-Leitsatz: „Das einzige, was wirklich stört, ist der Kunde!“ :wink:

Danke Micha für deine Antwort, so funktioniert es auch ohne ODBC-Verbindung.

nur zur Sicherheit: das passiert bei jedem Start des cRM (und nicht des
Computers)

Natürlich passiert das bei jedem Start vom cRM hatte mich vorher nur in der Eile falsch ausgedrückt.

und bei allem Respekt: ist dein Einwand nicht etwas arg konstruiert? :slight_smile:
Dann hat der cRM (Erfassungsdatum) und die Terminverwaltung
(Erinnerungen) und vmtl. auch andere Anwendungen (z.B. eMail
Versendedatum) aber ein ganz andere „Herausforderungen“…

Wenn ich dabei an unsere QS denke, die dauernd ihre Systemzeit ändert um interen Tests mit anderen Programmen zu machen, dann ist es nicht arg konstruiert und dann muss ich auf die feste Zeit vom DB Server zugreifen, wenn ich irgendwelche Berechnungen mit dem Datum machen will. Deshalb kann den Windows-Benutzern auch leider nicht das Recht genommen werden ihre Systemzeit zu ändern.

Hi Marco,

und bei allem Respekt: ist dein Einwand nicht etwas arg konstruiert? :slight_smile:
Dann hat der cRM (Erfassungsdatum) und die Terminverwaltung
(Erinnerungen) und vmtl. auch andere Anwendungen (z.B. eMail
Versendedatum) aber ein ganz andere „Herausforderungen“…

Wenn ich dabei an unsere QS denke, die dauernd ihre Systemzeit ändert
um interen Tests mit anderen Programmen zu machen, dann ist es nicht
arg konstruiert und dann muss ich auf die feste Zeit vom DB Server
zugreifen, wenn ich irgendwelche Berechnungen mit dem Datum machen
will. Deshalb kann den Windows-Benutzern auch leider nicht das Recht
genommen werden ihre Systemzeit zu ändern.

Uaaahhh… :slight_smile: Solche Verbrechen begehe ich nicht mehr, denn das kann
(unabhg. vom cRM) echt ins Auge gehen, insbesondere beim Senden von
Mails (Maildatum ergibt sich aus der Client Uhrzeit, d.h. beim Empfänger
steht dann z.B. „1.1.1980“ als Maildatum und wird in seinem Mailclient
bei Sortierung nach Datum ganz unten - im schlimmsten Fall ausserhalb
des aktuell sichtbaren Bereichs - einsortiert und ist damit für immer
verschwunden), oder beim Editieren von Dateien (ich sag nur
Makefile-Dependencies - jede Quellcodeänderung wird partout nicht
compiliert und wirkt sich damit auch nicht aus, weil das obj durch
Datumstest „in der Zukunft“ liegt, auch wenn nun das Datum mittlerweile
wieder korrekt ist. Aus eigener Erfahrung kann ich sagen: Das zu finden
kann dauern! :wink: Oder in der Word-Briefvorlage das {Erstelldatum} -
kriegt man so im konkreten Brief dann nie wieder weg - außer man bügelt
das zu Fuss platt, wenn man es überhaupt bemerkt und nicht erst der
Empfänger!).

Außerdem: Wie wollt ihr dann die cRM-Feldtypen ‚Erfassungsdatum‘ +
‚Änderungsdatum‘ und insbesondere nicht fällig-werdende Erinnerungen
(„Meeting 06.02.2008 um 16:00“, der Client hat gerade aber zufällig
1980) in den Griff kriegen?

Ich mixe daher niemals (mehr) Testsysteme mit meinem eigenen echten
System. Für „Datumstests“ verwende ich nur virtuelle Maschinen, weil man
die erstens zurücksetzen kann und zweitens komplett unabhängig vom
eigenen Arbeitsplatz (und der dort benutzten/installierten Software) ist
(z.B. auch falls eine andere Office Version getestet werden muss).

Vorschlag: bau in das Script nur einen Check ein, der guckt, ob das
aktuelle Datum um mehr als xxx Minuten von der Serveruhrzeit (via ADO
ermittelt) differiert und dann lauthals schreit (und nicht
stillschweigend versucht damit irgendwie klarzukommen)! Denn wie gesagt,
die Probleme eines falschen Datums sind vmtl. viel weitreichender, als
nur im cRM das eine Feld, das du jetzt evtl. autom. selber im Script
korrigieren könntest und möchtest.

just my 2 cents :wink:

Alex


CRM-Leitsatz: „Das einzige, was wirklich stört, ist der Kunde!“ :wink:

© combit GmbH