Entwickler-Ecke

Datenbanken - SQL-DB-Verwaltung im Novell-Netzwerk


kiwicht - Do 09.01.03 09:25
Titel: SQL-DB-Verwaltung im Novell-Netzwerk
Hallöchen...

ich hab mal ein etwas komplizierteres Problem:
Und zwar hab ich ein Programm geschrieben, das per SQL auf 4 DB zugreift. Die DataKontrol-Elemente werden zur Laufzeit mit den Datenbank-Feldern verknüpft (DBEdit1.DataField := Feld1 ... u.s.w.) Über eine CFG-Datei die im Root, also C: liegt, erhält das Programm die Informationen, wo diese DB´s liegen. Das Programm selber liegt auf einem durch Novell-Netware kontrolliertem Laufwerk. Die DB ansich liegen nochmal auf einem ganz anderen Laufwerk oder auf C: in eigene Dateien.

Will ich nun das Progg starten, sei es über Novell oder über Windows, erscheint jedesmal eine Fehlermeldung von wegen "Acces Violation" und dann "bei der Eingabe der Suchkriterien ist ein Fehler aufgetreten". In dem Progg werden anschließend keine Daten aus der DB angezeigt.

Ich bin bei Novell und Windows admin mit den entsprechenden Rechten, hab auch die Verzeichnisse für mich selber nochmal alle explizit freigegeben, aber trotzdem klappt es nicht. Wenn ich das Programm von meinem lokalem Arbeitsplatz "normal" ausführe, dann geht alles, es muss also mit Novel bzw. dem Netzwerk zusammenhängen.

Hat jemand von euch schonmal ein ähnliches Problem gehabt?`

Danke für die Hilfe

mfg
kiwicht


hansa - Do 09.01.03 20:13

Hi,

wie sieht es denn außerhalb Deines Programmes aus ? Ist da der Zugriff auf den Server möglich ? Hast Du die verfügbaren Laufwerke gemappt ??

Gruß
Hansa


kiwicht - Fr 10.01.03 09:12

du meinst unter der windows-oberfläche?
das ist alles freigegeben. In der Novell-Netzwerk-Umgebung seh ich ja auch mein Programm. Und wenn ich zum Beispiel mit dem WinCommander in das Verzeichnis wechsle, kann ich Datein löschen, erstellen und verschieben wie ich will.
Die Freigaben für das Verzeichnis sind also alle da. Das Programm schafft es ja auch, die temporären Datein für die SQL-Abfrage zu erstellen, die sehe ich ja dann zur Laufzeit in dem Verzeichnis (qsql...dbf)

Ich hab jetzt auch mal das Progamm so umgechrieben, das es die Konfig in seinem eigenen Vereichnis, also nicht mehr im Root sucht. Klappt auch nicht.

Ich vermute das mein Programm, weil es ja die BDE für die SQL-Verarbeitung braucht (oder nicht?!?), noch auf irgendwelche anderen Verzeichniss lokal zugreifen will. Das es daran liegt? Hilfe... :cry:


smiegel - Fr 10.01.03 10:44

Hallo,

am Novell-Netzwerk liegt es nicht.

Aus Deiner Fehlerbeschreibung werde ich leider nicht ganz schlau. Kannst Du etwas detaillierter werden?

Wie wird die Config-Datei ausgelesen? Wie wird sichergestellt, dass die benötigten DB-Tabellen auch gefunden werden? Sind alle Laufwerk-Mappings gleich? Wird das Programm auf mehreren Rechnern ausgeführt (BDE überall installiert?) oder auf welchem Rechner tritt das Problem auf?


kiwicht - Fr 10.01.03 11:13

ok.. also nochmal genau:

1. verknüfpung zum programm wird über "von novell gelieferte anwendungen" geöffnet

2. die erste fehlermeldung:
Acces violation at adress ..... in module pegelsuche.exe read out of address ....

3. ok gedrückt.. dann die zweite fehlermeldung:
bei der eingabe der suchkriterien ist ein fehler aufgetreten

4. wieder ok gedueckt, programm startet, aber alle dbedit-felder sind leer, genau wie die grid´s.

Die Verzeichnisse der DB´s werden wie gesagt aus einer Konfig-Datei gelesen, die sich mittlerweile direkt im Programmverzeichniss befindet.
Die Routine zum Auslesen dürfte wohl standard sein:

Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
       ini := TIniFile.Create('vorfisch.cfg');
        dirFirmendt := ini.ReadString('Verzeichnis','firmendt','');
        dirFirmentxt := ini.ReadString('Verzeichnis','firmentxt','');
        dirVorgbuch := ini.ReadString('Verzeichnis','vorgbuch','');
        dirSchadort := ini.ReadString('Verzeichnis','schadort','');
        dirFileLink := ini.ReadString('Verzeichnis','filelink','');

        ini.free;


danach wird den Query´s der DB´s zur Laufzeit über DatabaseName die entsprechende DB zugeordnet. Dann werden alle Daten per SQL und SELECT * FROM... angezeigt. etc.
Das ganze findet in einer TRY - EXCEPT-Schleife statt.
Sollte hier ein fehler auftreten, wird ein Formular aufgerufen, in dem ich die Verzeichnisse neu bestimen kann.

Was dann noch alles passiert, dürfte wohl uninteressant sein.

Fakt ist:
BDE ist installiert.

Fakt ist auch:
Das Programm funktioniert auf dem Entwicklungs-Rechner ohne Einwände!

Und Fakt ist außerdem, und das ist ja das verwirrende:
Das Programm funktioniert, wenn ich es auf dem Arbeitsrechner LOKAL ausführe, und es funktioniert auch, wenn ich es in einer von der WINDOWS-FREIGABE kontrollierten netzwerk-ressource ausführe.

Es klappt halt nur nicht mit der Novel-Freigabe, die ich aber definitv brauche!

*snif* .... ich bin der Verzweifelung soooo nahe..... :roll:

danke erstmal für eure bemühungen und anteilnahme ... ;)

mfg


kiwicht - Fr 10.01.03 11:17

achso.. beinahe vergessen.. sorry:

Zitat:

Sind alle Laufwerk-Mappings gleich? Wird das Programm auf mehreren Rechnern ausgeführt (BDE überall installiert?) oder auf welchem Rechner tritt das Problem auf?


Die Mappings stimmen. wie gesagt, mittlerweile liegen ja ALLE benötigten dateien, cfg-datei und db´s, in dem gleichen verzeichnis.

im moment bin ich noch der einzige nutzer des programmes, wird also nicht gleichzeitig wo anders ausgeführt...


hansa - Fr 10.01.03 11:17

Hi,

als was bist Du denn eingelogged ? Zum testen würde ich immer "Supervisor" verwenden, aber so schlau bist Du wohl auch. 8)

Gruß
Hansa


Sven - Fr 10.01.03 11:27

Da Du die BDE verwendest: verwendest Du die Datei PDOXUSRS.NET? Hast Du die Pfade für NetFileDir und PrivateDir gesetzt?


kiwicht - Fr 10.01.03 11:59

Zitat:

als was bist Du denn eingelogged ? Zum testen würde ich immer "Supervisor" verwenden, aber so schlau bist Du wohl auch.

.... admin.... ich denke das reicht aus... ;)

Zitat:

Da Du die BDE verwendest: verwendest Du die Datei PDOXUSRS.NET? Hast Du die Pfade für NetFileDir und PrivateDir gesetzt?

... ähhh... jetzt werd ich stutzig.... die datei kenn ich, heisst bei mir aber etwas anders: PDOXUSRS.LCK. die erstellet er, wenn sie nicht da ist, in dem Programm-Verzeichniss..... ich dachte erst die kommt von Novell??
Und die Pfade, die du da nennst, hör ich zum ersten Mal. Wo muss ich die setzten? Bei der BDE?? :oops:

mfg

PS: DANKE DANKE DANKE das ihr mir helft... ich wär sonst total verloren.... :roll:


hansa - Fr 10.01.03 12:41

Hi,

Zitat:
.... admin.... ich denke das reicht aus...


Im Novell-Netzwerk heißt derjenige, der alle Rechte hat aber nun mal SUPERVISOR :!: Admin ist so was wie Karl-Heinz. 8) Nicht, daß es doch noch an sowas liegt.

Gruß
Hansa


kiwicht - Fr 10.01.03 13:24

Hm... das stimmt natürlich.

Ich hab aber jetzt nochmal nachgeschaut, und mir für das Verzeichniss (inkl. der enthaltenen Dateien) explizit selber Supervisor-Rechte zugeordnet...
allein die tatsache das ich das kann, heisst doch eigentlich schon, das ich auch der nutzer mit den höchsten rechten bin, oder?
jedenfalls klappts trotzdem nicht... :(

ich denk schon, das die rechte für die Programm-Datein ausreichen, aber ich vermute halt, das das Programm noch irgendwo anders drauf zugreift, wo es noch keine freigaben zu hat!?!

mfg


smiegel - Fr 10.01.03 13:55

Hallo,

an den Rechten liegt es nicht. Das einzige was benötigt wird, sind Schreib- und Leserechte auf die entsprechenden Verzeichnisse.

So wie es aussieht, deutet alles auf einen Konfigurationsfehler der BDE hin.

In der Systemsteuerung kannst Du in der "BDE-Verwaltung" unter "Konfiguration" - "Treiber" - "Native" - "Paradox" das Net-Dir einstellen, in dem sich die "pdoxusrs.net" befindet. Bei mir ist dort "C:\" eingestellt.

Mit diesen Einstellungen und ohne Supervisor- und Adminrechte kann ich Querys und DBF's abfragen usw.


Sven - Fr 10.01.03 13:57

Ich bin gerade auf dem Sprung und kann deshalb nicht selber schauen. Sieh doch mal in die Delphi-Hilfe. Da steht etwas über die Pfade NetFileDir und PrivateDir.


kiwicht - Fr 10.01.03 19:44

Zitat:

Sieh doch mal in die Delphi-Hilfe. Da steht etwas über die Pfade NetFileDir und PrivateDir.


*moep* .... die ist englisch... aber naja, ich hab mich durchgekämpft... war am ende aber auch nicht sehr vielsagend, weil ich ja im grunde nur das zur laufzeit ändern könnte, was ich so ja schon über den bde-admin getan habe... siehe den hinweis von smiegel

aber mir ist gerade was anderes aufgefallen:
und zwar mein verweis zu der INI-Datei. Der ging ja erst auf c:\dbprog.ini. Als ich dann der Meinung war, das mein Programm nicht auf C: zugreifen kann, von wegen novel-freigabe und so, hab ich den verweis auf das programm-verzeichnis ändern wollen: also einfach:

"TIniFileCreate('dbprog.ini');

kann es sein das es daran liegt? findet er die INI nicht, weil das keine korrekte, relative Pfadangabe ist??

mfg & big thx
kiwicht[/code]


hansa - Fr 10.01.03 19:52

Hi,

Zitat:
. Als ich dann der Meinung war, das mein Programm nicht auf C: zugreifen kann
:hair: Ist das da Dein Ernst ? Außerdem : In der BDE einen User "Admin" anzulegen, was soll Dir das bei Novell bringen? Das hab ich Dir doch schon gesagt. Da heißt der Oberaufseher eben SUPERVISOR und eben nicht Admin!

Gruß
Hansa


kiwicht - Fr 10.01.03 23:55

:oops: aber ich hab doch alles was ich brauch als admin bei netware... und über mir steht doch bei uns auch kein anderer..... ich versteh das nicht ganz.... andererseits, ich geb mir doch selber, als admin, die vollen supervisor-rechte bei der nutzung des verzeichnesses. also kann es doch darin nich wirklich liegen. das der admin nicht der ober-master ist, möcht ich dir gerne glauben, aber wenn ich nunmal als admin alle rechte eines supervisors habe?!

Zitat:
In der BDE einen User "Admin" anzulegen, was soll Dir das bei Novell bringen?

da musst du was falsch verstanden habe... ich bin bei novel als admin angemeldet, mit, meiner meinung, supervisor-rechten... und im novel-administrator, also dem prog um user und programme hinzuzufügen, hab ich dem admin, also mir, für mein programm volle supervisor-rechte zugewiesen.
in der bde hab ich jetzt nur versucht das über die einstellungen für die NetDir von Paradox hinzubiegen, was ja letztenendes auch nicht die lösung war.... :(

das mit C: mein ich so:
ich kann bei novel in den eigenschaften von dem Prog ja ein arbeits-verzeichnis festlegen. meines erachtens genau eins! vorher war mein prog so geschrieben, das es die ini-datei auf C: gesucht hat. das klappt zwar wenn ich es lokal ausführe, aber auf dem novel-server gehts nich mehr.
also hab ich dem programm gesagt: suche die ini jetzt immer im programm-verzeichnis. weil das hat mittlerweile alle möglichen freigaben die es nur geben kann in windows und novell.
meine vermutung war jetzt: ich hab die relative pfad-angabe im TIniFile.Create-Teil falsch geschrieben....

tja, und da steh ich jetzt.. max in der sonne mitn schlips aufn rücken... ;)
außerdem isses schon spät, ich bin müde und kann kein delphi mehr sehen.... :roll:

mfg
kiwicht


smiegel - Sa 11.01.03 10:41

Hallo,

hast Du einmal mit FileExists bzw. PathExists geprüft, ob die Ini-Datei bzw. die ausgelesenen Pfade auch existieren. Deine Vermutung, dass er die Ini-Datei nicht findet, scheint des Übels Wurzel zu sein.

Mit ExtractFilePath(ParamStr(0)) erhälst Du den aktuellen Pfad Deines Programmes.

Wenn Du relative Pfade benutzen willst, musst Du die UNC-Schreibweise benutzen: z.B. //mein_server/mein_DatenVolume/mein_Pfad.

Wie schon einmal erwähnt: es werden keine Admin- oder Supervisor-Rechte benötigt. Das Programm braucht nur Rechte (Lesen, Schreiben) für das Verzeichnis in dem es sich befindet.

Meine Programme funktionieren seit Jahren auf diese Weise in einem Novell-Netzwerk mit über 250 Clients.


kiwicht - Sa 11.01.03 11:51

Zitat:

hast Du einmal mit FileExists bzw. PathExists geprüft, ob die Ini-Datei bzw. die ausgelesenen Pfade auch existieren... Mit ExtractFilePath(ParamStr(0)) erhälst Du den aktuellen Pfad Deines Programmes.


das ist ne gute idee, das werd ich zuerst mal ausprobieren... wenn´s am ende dann doch daran lag, wär das ja mehr als peinlich... :oops:

Zitat:

Wenn Du relative Pfade benutzen willst, musst Du die UNC-Schreibweise benutzen: z.B. //mein_server/mein_DatenVolume/mein_Pfad.

was du meinst ist glaub ich die absolute pfadangabe, nämlich wenn ich das Laufwerk und das Verzeichniss direkt bestimmen kann, weil die adresse von jeder arbeitsstation aus die gleiche wäre.

Was ich meine ist aber, verglichen mit DOS:

../inifiles/dbprog.ini

Also, eine Verzeichnissebene höher, und dann in das Verz. inifiles...oder halt.
Aber das ist ja erstmal nebensächlich, ich schau mal wo mein Programm so rumwühlt.

Danke nochma vielmals für die Bemühungen!!

mfg

kiwicht


kiwicht - Mo 13.01.03 09:14

Also den Urheber sämtlichen Ärgers hab ich gefunde, es war, ganz genau, die ini-datei.

Das Problem ist einfach, das ich nich wirklich weiss, wie ich meinem Programm sage, das die ini sich im GLEICHEN verzeichniss befindet.

Bisher hieß es immer:
ini := TIniFile.Create('dbprog.ini');

er sucht damit aber mitnichten im eigenen Verzeichnis, sondern entweder garnicht, weil falsche Syntax, oder ganz woanders.

Daher wiederhol ich noch einmal mit dringlichem Nachdruck ( :wink: ) meine frage, um die Problematik präzise auf den Punkt zu bringen: :lol:

Wie ist die Syntax in Bezug auf relative Ortsangaben im
"eigenen" Verzeichnis ?

thx
kiwicht

ps. allen anwesenden einen schönen guten morgen, aus dem zugeschneiten Berlin :D


LCS - Mo 13.01.03 09:16

Hi
eine Möglichkeit:

Quelltext
1:
ini := TIniFile.Create(ExtractFilePath(Application.ExeName) + 'dbprog.ini');                    


Gruss Lothar


kiwicht - Mo 13.01.03 10:50

Hm... also langsam zweifel ich an mir selber.... bis zur klappse fehlt jetzt echt nicht mehr viel... :x :? :(

Der Tip von LCS is ja schonma nice, hab ich gleich angewandt.

Ich hab also jetzt in meinem Progg die Routine, die überprüft, ob die dbprog.ini existiert:

if NOT FileExists(ExtractFilePath(Application.ExeName) + 'dbprog.ini') then
SetupForm.ShowModal;

in dieser SetupForm wird einfach nur eine neue Ini erstellt mit den vom Anwender angebenen Verzeichnissen.

Danach werden dann die Datenbanken-Verz. aus dieser INI gelesen, und die ganzen Query´s DBEdit-Felder zugeordnet.

Fertig.

Und jetzt das schönste: Das Programm stirbt an der SetupForm.ShowModal - anweisung. Hab auch SetupForm.Show versucht, oder den Befehl in einem anderen Kontext.... nix.... *heul* .... das leben is nich fair!

Aber die Syntax stimmt doch! Es hat doch bisher immer mit diesem Aufruf geklappt.. und nu auf einma nich mehr????

hülfe... büdde.....


Sven - Mo 13.01.03 11:39

Hast Du zu SetupForm ein OnShow-Ereignis deklariert. Wenn ja, dann schau dort doch mal hinein. Evtl. kann der Fehler, wäre schön zu wissen wie der genau heißt, dadurch entstehen, daß in der Routine auf etwas zugegriffen wird, was noch nicht existiert. Falls vorhanden poste mal Deinen Quellcode zu dem OnShow-Ereignis.


smiegel - Mo 13.01.03 11:56

Hallo,

kannst Du einmal den Code posten, in dem Du die SetupForm aufrufst, eventuell sogar die SetupForm selber.

Oder, wenn Du willst, kannst Du den Code auch an meine EMail-Adresse senden.


kiwicht - Mo 13.01.03 11:57

Der Leidensweg des kiwicht x. aus b. an der s.

So leudde, auch wenn euch mein Problem langsam stresst, das muesst ihr euch noch durchlesen, ich verabschiede mich derweilen in die psychatrische klinik.

Programmcode geändert auf:

if NOT FileExists(ExtractFilePath(Application.ExeName) + 'dbprog.ini') then begin
... aus einem öffnen-dialog das verzeichniss für die db auslesen, und
mit folgendem in eine ini im Prog-Verzeichniss schreiben
ini := TIniFileCreate(ExtractFilePath(Application.ExeName) + 'dbprog.ini')
ini.WriteString...

Problem hier:
Ich hab das Prog compiliert und auf den arbeitsrechner kopiert, und siehe an, es geht nicht, weil der wert Application.ExeName IMMER NOCH auf das Verzeichniss vom Entwicklungsrechner zeigt!

Also hab ich Application.ExeName ersetzt durch ParamStr(0).

Klappt erstmal schon besser, weil das Prog jetzt tatsächlich zur Laufzeit das eigene Verzeichnis bestimmt.

Nächstes Prob:
NUR (!) die prog.-datei also in ein verzeichnis LOKAL kopiert, um zu testen, ob die routine auch wirklich funktioniert!
Und sie tut. Jedenfalls lokal.
Also die Prog.Datei, wieder allein, OHNE ini, auf das Netz-LW.
Erste Start. Zack. Funktioniert.

Dacht ich schon: Grund zur Freude, ich habs geschafft!

Denkste.

Nochmal ausgeführt. Fehlermeldung:
"Unknown Internal Operation Error. Lock Violation.
File: bla bla\bla bla\PDOXUSRS.LCK" ... und die Datenbanken, die er beim ersten Start so wunderbar gelesen hat, liest er jetzt auch nicht mehr.

Ich mir kurz an kopf gefasst. Alle Dateien wieder aus dem Verzeichnis gelöscht bis auf die exe, ausgeführt, klappt. nocham ausgeführt. klappt nicht. der ini und der o.g. *.lck nochma explizit für meinen account ALLE rechte gegeben. ausgeführt. klappt nicht.

nochma: alle gelöscht bis auf die exe. alle db´s in das programmverzeichnis im Netzt kopiert. ausgeführt. aha. ich darf im öffnen.dialog zwar noch die db´s auf dem netzlaufwerk angeben, aber danach kommt ma ne andere fehlermeldung:
"unknown internal operating system error. file or directory does not exist. File: bla bla\bla bla\PDOXUSRS.LCK. Lock Violation"

Aha. Logisch. Hab ich ja gelöscht. Hätt ich sie nicht gelöscht, wär die andere Fehlermeldung gekommen....

schöne grüße aus der anstalt, mein arzt meint ich soll mich der löwen-bändigung widmen, ist nich ganz so aufregend...


LCS - Mo 13.01.03 12:19

kiwicht hat folgendes geschrieben:
Hm... also langsam zweifel ich an mir selber.... bis zur klappse fehlt jetzt echt nicht mehr viel... :x :? :(

Bwahren Sie Ruhe, Sie werden gerettet :mrgreen:

kiwicht hat folgendes geschrieben:

Ich hab das Prog compiliert und auf den arbeitsrechner kopiert, und siehe an, es geht nicht, weil der wert Application.ExeName IMMER NOCH auf das Verzeichniss vom Entwicklungsrechner zeigt!

Also hab ich Application.ExeName ersetzt durch ParamStr(0).

Das hör ich zum ersten Mal. Das ist nämlich ein- und dasselbe.

Das Problem mit deinen Lock-Fehlern liegt daran, dass kein globles NetFileDir existiert. Der Hinweis tauchte weiter oben schon mal auf. Schmeiss die ganzen, eventuell vorhandnen .LCK Dateien raus, sorge dafür, dass auf allen PC NetFileDir auf ein erreichbares Netzwerklaufwerk verweist (entweder über BDE-Einstellung oder vom Programm aus), dann sollte das hinhauen.

Gruss Lothar


kiwicht - Mo 13.01.03 12:47

Zitat:

Schmeiss die ganzen, eventuell vorhandnen .LCK Dateien raus, sorge dafür, dass auf allen PC NetFileDir auf ein erreichbares Netzwerklaufwerk verweist (entweder über BDE-Einstellung oder vom Programm aus), dann sollte das hinhauen.

gemacht. hab die lck gelöscht, und die *.net von C: ins Netz kopiert, da wo auch mein Programm liegt. Dann das netfile-LW mit dem BDE-Admin auf dieses jenes verzeichniss gesetzt, gespeichert, und los.

und dann kommt wieder die lock-violation-meldung... und über novell ist alles freigegeben... 8|

zu dem setup-form problem:
das hab ich ja im grunde durch meine open-dialog-routine gelöst, aber hier trotzdem nochma die oncreate.proc vom setup.form:


Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
  try
        ini := TIniFile.Create(ExtractFilePath(Application.ExeName) + 'dbprog.ini');
        dirDatBase := ini.ReadString('Verzeichnis','db1','');
[... und noch n paar andre...]
  finally
        ini.free;
  end;
EditDB1.Text := dirDatBase;


und im Form1, also meinem HauptForm steht einfach nur
SetupForm1.Show oder halt ShowModal;..

narf...


LCS - Mo 13.01.03 12:53

kiwicht hat folgendes geschrieben:

gemacht. hab die lck gelöscht, und die *.net von C: ins Netz kopiert, da wo auch mein Programm liegt. Dann das netfile-LW mit dem BDE-Admin auf dieses jenes verzeichniss gesetzt, gespeichert, und los.

und dann kommt wieder die lock-violation-meldung... und über novell ist alles freigegeben... 8|

Bin mir nicht ganz sicher, aber glaube mich zu erinnern, dass NetDir auf ein Rootverzeichnis verweisen sollte.

Gruss Lothar


kiwicht - Mo 13.01.03 13:23

hab ich gemacht... klappt nicht. Gleiche Fehlermeldung.
Zumal ich dann ja wieder das Problem habe, so glaub ich, das mein Programm ja nur im eigenen Verzeichnis lesen darf. Führt also wieder auf Konfig-Probleme mit Novell hinaus, da ich da ja nur explizit ein Verzeichniss als Arbeitsverzeichnis angeben kann....

----fazit-------
ich hab mich entschlossen das thema ganz zu lassen.

lokal ausgeführt funzt mein Programm bei installierter BDE ja auf jedem Rechner. Das war zwar nich mein arbeitsziel, aber ist wenigstens schon mal ein Teilerfolg.

Ich vermute einfach mal das die ganze geschichte mit SQL und Novell nicht zusammen passt.

Ich danke für eure rege teilnahme und die vielen lösungs-hinweise, falls noch kreative beiträge kommen werd ich natürlich versuchen diese umzusetzen, aber aktiv beschäftigen werd ich mich nicht mehr mit diesem thema. btw waren eure tips natürlich nicht umsonst, denn schließlich hat das programm ja vorher nicht einmal lokal auf fremden rechnern gefunzt.. ;)

ein großes danke an alle
mfg
kiwicht


Sven - Mo 13.01.03 14:20

Um noch einmal auf die PDOXUSRS.net zurückzukommen. Diese sollte für jeden Rechner lokal auf C:\ liegen; auch wenn das Programm selber irgendwo im Netz liegt.
Dazu mußt Du NetFileDir und PrivateDir im Programm ferstlegen z.B. so:

Quelltext
1:
2:
3:
  DatabasePath := 'I:\install.dat\BetterFM\'; 
  Session.NetFileDir := DatabasePath + 'Datenbank';
  Session.PrivateDir := ExtractFilePath(Application.ExeName) + 'TMP';

Also NetFileDir muß auf das Verzeichnis mit Deiner Datenbank verweisen.

Gruß Sven


kiwicht - Mi 15.01.03 16:03

Ich bin der glücklichste Programmierer der Welt:

Ich hatte 2. Posts vorher zwar schoneinmal resigniert, aber das aufgeben viel mir dann doch schwer, und so habe ich mir nächtelang den kopf zerbrochen, und es endlich doch geschafft!

Ich weiß, der folgende Code wurde ganz am Anfang schon mal gepostet, u.a. von Sven und LCS u.s.w., aber da dachte ich, der funzt nit, weil Novell meinem Progg den Zugriff auf die Client-Roots verbietet! Mitnichten, ich bin nur falsch an die Sache rangegangen!


Quelltext
1:
2:
Session.NetFileDir := 'C:\'; 
 Session.PrivateDir := 'C:\';


Zack, und jede Station bei uns speichert erstens seine TMP-SQL-Dateien und zweitens die NET-Datei im eigenen Root!

HERRRLICH! ES FUNKTIONIERT!

ein herzliches Dankeschön an alle Hinweise und beiträge

mfg
kiwicht

ps. das ini-file-problem hab ich auch einfach umgangen, indem ich die registry benutze... manchmal liegt das einfach so nah..... [/list][/quote]