+1 800 256 3608 (toll-free in North America) or +49 7531 90 60 10| service@combit.com

LL und Terminalserver


(Guest) #1

Hallo NG,

bei meiner Anwendung kann der Benutzer per Dialog (Aufruf LlPrinterSetup) den Drucker für einen Beleg auswählen. D.h. die crp- bzw. lsp-Datei wird dann erstellt. Bei einer klassischen Client-Server-Installation kann damit individuell auf jedem Client ein Drucker eingestellt werden, da jede Client-Installation die LL-Projektdateien enthält.

Nun soll die Anwendung unter einer Terminal-Server-Umgebung eingesetzt werden. Ist dies ohne weiteres, d.h. ohne Programmänderungen möglich? Oder gibt es dann Probleme mit der Druckersteuerung?

Kenne leider Terminal-Server nicht genau, aber das Programm wird dort ja wohl nur einmal installiert und damit auch die LL-Projektdateien, also z.B. lst- und lsp-Datei. Verwenden nun alle Sessions den selben Drucker, da auf Terminal-Server nur eine lsp-Datei???

Bin für jede Hilfe dankbar, habe leider keinen Terminal-Server zum Testen.

Gruß Dieter


(Guest) #2

Hallo Dieter,

Kenne leider Terminal-Server nicht genau, aber das Programm wird dort ja
wohl nur einmal installiert und damit auch die LL-Projektdateien, also
z.B. lst- und lsp-Datei. Verwenden nun alle Sessions den selben Drucker,
da auf Terminal-Server nur eine lsp-Datei???

ja, nur eine lsp-Datei, wenn du nichts anderes definiert hast. D.h. jeder
Benutzer müsste dann sein eigenes LL-Verzeichnis für die Projektdateien
verwenden. Das wird auf Dauer schon unübersichtlich. Abgesehen davon: Wenn
dein Programm auch noch andere temporäre Dateien erzeugt, dann musst du
sowieso grundsätzlich etwas ändern.

Bei der Umstellung meiner Software bin ich so vorgegangen:

  1. Alle LL-Projektdateien in einer Datenbank speichern. Hat den großen
    Vorteil, dass die Projektdateien dann automatisch für alle User zur
    Verfügung stehen und nur ein einziges mal verwaltet werden müssen.
    Zusätzlich noch einfachere Installation und Distribution: Wenn ich für einen
    Kunden Änderungen machen muss, schickt er mir einfach die Listen-Datenbank
    (die ich zuvor automatisch zippe) per E-Mail, direkt aus dem Programm
    heraus.

  2. Beim Druck wird die Projektdatei aus der Datenbank in ein
    Benutzer-Verzeichnis kopiert. Den Pfad hole ich mir über das Win-API mit
    SHGetFolderPath(…CSIDL_PERSONAL…) und hänge dann noch meine
    Programm-Bezeichnung ran. Die lsp-Datei speichert LL ja dann automatisch im
    selben Ordner.

  3. Beim Aufruf des Designers wie [2] jedoch merke ich mir vor dem Aufruf das
    Dateidatum und kann somit feststellen, ob der Anwender Änderungen an der
    Projektdatei vorgenommen hat. Wenn “ja” wird die Datei einfach in die
    Datenbank zurückgeschrieben.

Abgesehen vom Terminalserver-Einsatz ist diese Vorgehensweise auch unter
Vista unproblematisch, da jeder User in seinem User-Directory Vollzugriff
hat bzw. unbedingt braucht (lsp-Datei erstellen…).

Gruß
Otto


(Guest) #3

Hallo Dieter,

beim Einsatz von LL auf einem Terminal-Server habe ich folgendes
festgestellt:

1.)
Den zu verwendenten Drucker musst Du benutzerbezogen verwalten (z.Bsp. in
einer Configdatei des Programms)
und vor dem Erstellen der Vorschaudatei mit Hilfe von
“Core.LlSetPrinterInPrinterFile(…)” zuweisen.
Ich habe mir auch angewöhnt nach dem Erstellen der LL-Datei die
Druckerbeschreibungsdatei
sicherheitshalber gleich wieder zu löschen (Core.LlSetPrinterToDefault(…))

2.)
Das gleichzitige Erstellen einer Vorschaudatei durch verschiedene Nutzer
funktioniert nur,
wenn Du die Vorschaudatei für jeden Benutzer in einem eigenen Verzeichnis
erstellst.
Wenn Du die LL-Datei in einem für alle Nutzer gemeinsamen Verzeichnis
erstellst,
kann immer nur einer einen Report benutzen, da die LL-Datei vom System
blockiert wird.
Ich übergeben dazu der Print()-Methode ein benutzerbezogenes
Temp-Verzeichnis als Ausgabeziel für die LL-Datei.

Der Zugriffskonflikt tritt übrigens auch immer dann auf, wenn man versucht
innerhalb eines Programms den gleichen Report mehrmals parallel zu
erstellen.
Dies kann man nur verhindern, indem man für jeden Aufruf einen anderen Namen
für die Vorschaudatei vergibt
(Core.LlSetOptionString(LlOptionString.PreviewFileName, “Meine_LLDatei”)).
Diese Methode funktioniert aber erst ab der 13er-Version von LL korrekt!
Zumindest bei der dotNET-Version.
Bis zur 12er-Version gibt es einen Fehler, wenn man als Ausgabziel das
PreviewControl angibt.

Ich hoffe, ich konnte Dir etwas weiterhelfen.

Mit freundlichen Grüßen
Carsten


(Guest) #4

Danke an Euch beide, das hilft mir erst mal weiter.

Gruß Dieter


(Guest) #5

On Tue, 6 May 2008 02:24:07 +0200, “Otto Herdegen”
<otto.herdegen@rubin-so…> wrote:

Hallo Otto,

Bei der Umstellung meiner Software bin ich so vorgegangen:

  1. Alle LL-Projektdateien in einer Datenbank speichern. Hat den großen
    Vorteil, dass die Projektdateien dann automatisch für alle User zur
    Verfügung stehen und nur ein einziges mal verwaltet werden müssen.
    Zusätzlich noch einfachere Installation und Distribution: Wenn ich für einen
    Kunden Änderungen machen muss, schickt er mir einfach die Listen-Datenbank
    (die ich zuvor automatisch zippe) per E-Mail, direkt aus dem Programm
    heraus.

wir stehen vor dem gleichen Problem (bei ca. 1000 Usern wird es
wirklich unübersichtlich). Könntest du etwas genauer sagen, wie du die
Projekte speicherst - es gibt da ja diverse Möglichkeiten. Im Moment
denken wir darüber nach das Projekt in einem Text Feld (MS SQL Server)
ablegen - haben unsere “Forschungen” aber noch nicht begonnen.
Vielleicht kannst du uns ja einige Sackgassen ersparen.

TIA

regards

   Uwe Hein

Uwe Hein Folkwang Musikschule der Stadt Essen / Germany
DevGroup-Ruhrpott.net


(Guest) #6

Hallo Uwe,

meine Listendatenbank hat folgenden Aufbau:

TYP=>Numerisch: Beinhaltet den Projektdatei-Typ. Dient zur
Unterscheidung/Zuordnung des Formulares zum Programmteil, z.B.
Auftragsbearbeitung, Bestellwesen, Kasse usw.

FILENAME=>String: Beinhaltet den physikalischen Dateinamen der Projektdatei,
einschließlich Dateierweiterung.

LISTBEZ=>String: Die Projektbezeichnung aus der Projektdatei, Section
“[Description]”, Wert “Text”. Hintergrund: Wenn die vorhandenen Listen in
einem DBGrid dargestellt werden sollen/müssen dann dauert es viel zu lange
jedes mal die Beschreibung aus der Section heraus zu lesen, also speichere
ich sie separat in einem String-Feld.

DATUM=> Datum der letzten Änderung

TABLENAME=>String: Beinhaltet den Tabellen-Namen

INDEXNAME=>String: Beinhaltet den zu verwendenden Index für den Ausdruck

FILTER=>String: Beinhaltet einen String zur Filterung der zu druckenden
Daten. Ist zudem vorgesehen als alternative Verwendung für ein SQL-Script.

LST=>Blob: Hier wird die eigentliche Projektdatei gespeichert. Ein Textfeld
verwende ich nicht, weil in meinen Formularen (speziell bei den Formularen
für die Auftragsbearbeitung) oft Grafiken mit eingebunden sind. Die
Integration der Grafikdaten in die jeweilige Projektdatei ist erforderlich,
weil ansonsten die Clients im Netzwerk wieder physikalischen Zugriff auf die
Grafikdateien haben müssen, verbunden mit den entsprechenden Problemen und
darum: Wenn ich schon eine Client-Server-Datenbank verwende, dann möchte ich
das auch konsequent umsetzen. D.h. in meinem Programm benötigt kein Client
physikalischen Zugriff auf irgend eine Datei auf dem Server. Alles wird in
den Datenbanken gespeichert, sogar Textdateien (Textbausteine), Archivdaten,
Grafiken. Demzufolge muss ich bei der Installation keine Freigabe oder ein
Netzwerklaufwerk einrichten. Das war früher ein Problem. da waren die
LL-Dateien auf dem Server gespeichert und jeder Client musste darauf Zugriff
haben. Die Shares einzurichten oder die Netzwerklaufwerke war bei der
Installation ziemlich aufwändig. Heute entfällt das alles, der Anwender muss
nur mehr die CD einlegen und ein paarmal auf “OK” oder “Weiter” klicken und
ein Server oder ein Arbeitsplatz ist betriebsbereit installiert.

Zum Speichern der Dateien generell kann ich nicht viel sagen, da ich mit SQL
nicht arbeite. Habe den Nexus-Server im Einsatz (www.nexusdb.com) und
verwende ausschließlich die VCL-Komponenten. Diese bieten Methoden (so wie
man es von der BDE und den TTable-Komponenten kennt) um Dateien in die
Memofelder zu laden oder aus den Memofeldern zu speichern.

Es gibt aufgrund der Datenbank-Speicherung im Netzwerk auch keine
Zugriffs(Locking-)probleme. Das war bei der Designerstellung ein wichtiges
Thema. Es sollte z.B. möglich sein, dass während ein Anwender eine Änderung
einer Liste vornimmt die anderen User weiterhin mit der ursprünglichen Liste
weiter arbeiten können und nicht blockiert sind. Selbst wenn ein User
stundenlang eine Projektdatei editieren würde, er arbeitet ja immer mit
einer lokalen Kopie auf seinem Rechner, respektive beim Einsatz im
Terminalserver in seinem eigenen Userverzeichnis. In diesem Zusammenhang
würde es noch Sinn machen ein paar weitere Blob-Felder für die
unterschiedlichen “Versionen” der Projektdatei zu reservieren.
Beispielsweise um eine “Undo”-Option zur Verfügung zu haben.

Das ist so aus dem Stehgreif heraus das Wichtigste was mir gerade dazu
einfällt. Hoffe es hilft dir etwas weiter.

Viel Erfolg und freundliche Grüße
Otto


(Guest) #7

On Thu, 8 May 2008 01:31:10 +0200, “Otto Herdegen”
<otto.herdegen@rubin-so…> wrote:

Hallo Otto,

meine Listendatenbank hat folgenden Aufbau:

Das ist so aus dem Stehgreif heraus das Wichtigste was mir gerade dazu
einfällt. Hoffe es hilft dir etwas weiter.

vielen Dank für Deine Hinweise - das hat uns in der Tat einiges an
Arbeit gespart, weil wir - im Moment - z.B. nix mit Grafiken am Hut
haben und daher das Blob gar nicht auf dem Tacho hatten.

Uwe
Uwe Hein Folkwang Musikschule der Stadt Essen / Germany
DevGroup-Ruhrpott.net