Seite 2 von 4

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Fr, 22. Jun 2018 21:56
von Jan
Bei meinem Kunden läuft eine FOXCDX mit ca. 5 GB. Zuwachs 1 GB / Jahr.

Zugegebenermaßen liegt die in einem ADS. Aber trotzdem, es geht.

Jan

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Fr, 22. Jun 2018 23:05
von HaPe
Hallo Jan !
Bei meinem Kunden läuft eine FOXCDX mit ca. 5 GB. Zuwachs 1 GB / Jahr.
Zugegebenermaßen liegt die in einem ADS. Aber trotzdem, es geht.
Das zählt nicht (direkt), weil der ADS seine eigenen DBF-Treiber hat und deshalb vermutlich einen leicht modifizierten DBF-Header verwendet den XBase, Clipper, FoxPro und Konsorten nicht lesen können. :roll:
Wenn Michael natürlich seinen eigenen DBF-Treiber für den Server verwendet und nicht den von Xbase ist alles gut :D

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 0:42
von mikehoffmann
Nee, ich verwende gar keinen Treiber. Ich schicke nur die API-Calls weiter an den Server, der sie dann ausführt. Ob das nun dbf oder ntx oder xpf oder cdx oder sonst welche Dateien sind, ist mir Banane.

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 5:51
von Jan
HaPe hat geschrieben: Fr, 22. Jun 2018 23:05Das zählt nicht (direkt), weil der ADS seine eigenen DBF-Treiber hat und deshalb vermutlich einen leicht modifizierten DBF-Header verwendet den XBase, Clipper, FoxPro und Konsorten nicht lesen können. :roll:
Hans-Peter,

das ist nicht korrekt. Natürlich sehe ich auch das es einen Unterschied gibt, wenn die dbf unter der Fuchtel des ADS liegt. Aber der verändert an der dbf gar nichts. Ich kann die dbf von dem Server runter kopieren und einfach so weiter verarbeiten mit der normalen FOXCDX und ohne ADS. Da ist kein Unterschied in der dbf.

Jan

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 9:08
von mikehoffmann
und wo ist die maximal Grösse der Datenbank?
weet ik nich. Mein Umlenken unterstützt eine Dateigröße bis 2^64 Bytes. Ob man das unter dem großen Wagen auch kann, entzieht sich meiner Kenntnis, müsste man also mal probieren. Da man die Locks alternativ implementieren könnte, gäbe es von dieser Seite keine Einschränkungen.

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 9:17
von Jan
mikehoffmann hat geschrieben: Sa, 23. Jun 2018 9:08weet ik nich.
He snackt platt :shock: =D>

Jan

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 9:31
von brandelh
Jan hat geschrieben: Fr, 22. Jun 2018 21:56 Bei meinem Kunden läuft eine FOXCDX mit ca. 5 GB. Zuwachs 1 GB / Jahr.

Zugegebenermaßen liegt die in einem ADS. Aber trotzdem, es geht.

Jan
Mann JAN ... ADS verwaltet die wohl anders !

Wenn du mir einen 3 Zeiler schreiben kannst mit den Einstellungen, dass eine FOXCDX mit mehr als 2,4 GB erstellt und gepflegt werden kann, wäre das ein Argument das mich überzeugt :wink:

Bei meinen Tests erhalte ich beim Versuch in die DBF zu schreiben immer einen Laufzeitfehler, wenn die Dateigröße diesen Wert übersteigt.
Nur die Memodatei kann meines Wissens auf über 2 TB ansteigen, aber ich lasse mich gerne überzeugen :-)

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 9:59
von Jan
Hubert,

da mach ich nichts besonderes. Ich hab in einem ersten Schritt damals die normalen dbf von DBFNTX auf FOXCDX umgeschrieben. Das lief ein oder zwei Jahre so. Dann haben wir die in den ADS geschoben. Ohne weitere Umwandlung. Der Zugriff im ADS ist aber proprietär enigestellt, also keine Chance, da von außen neben dem ADS vorbei dran zu kommen. EIne Besonderheit ist, das wir die dbf im ADS als FoxPro einbinden, nicht als Visual FoxPro. Das war mal unter ADS 10 oder 11 so notwendig lt. Friedhelm. Heute mit der 12 geht das wohl auch per VFP, aber das ändern wir jetzt nicht mehr ab.

Die dbesys sieht so aus:

Code: Alles auswählen

DbeInfo(COMPONENT_DATA, DBFDBE_LIFETIME, 0)                                                        // Verweildauer von Records im lokalen Cache
DbeInfo(COMPONENT_ORDER, DBE_LOCKMODE, LOCKING_EXTENDED)                                           // Macht das die Massenabfertigung schneller? (29.10.2008)

DbeInfo(COMPONENT_DATA, FOXDBE_LIFETIME, 0)                                                        // Verweildauer von Records im lokalen Cache
DbeInfo(COMPONENT_ORDER, FOXDBE_LOCKMODE, LOCKING_EXTENDED)                                        // Macht das die Massenabfertigung schneller? (29.10.2008)
DbeInfo(COMPONENT_ORDER, CDXDBE_LOCKRETRY, 1000000)                                                // Lt. Aussage Till Warweg 26.08.2015 sinnvoll im Netzwerk

DbeInfo(COMPONENT_DATA, ADSDBE_LOCK_MODE, ADSDBE_PROPRIETARY_LOCKING)                              // dbf nur über ADS bearbeitbar
DbeInfo(COMPONENT_DATA, ADSDBE_TBL_MODE, ADSDBE_CDX)
DbeInfo(COMPONENT_ORDER, ADSDBE_TBL_MODE, ADSDBE_CDX)
DbeInfo(COMPONENT_DATA, ADSDBE_RIGHTS_MODE, ADSDBE_IGNORERIGHTS)
DbeInfo(COMPONENT_DATA, ADSDBE_TABLENAME_IS_ALIAS, .T.)

DbeSetDefault("ADSDBE")
Ich hab da beide Versionen drin, weil ich ab und an mal dbf von außerhalb des ADS einlese oder schreibe.

Ich hab gerade mal nachgeschaut: Die dbf ist in diesem Moment exakt 5.040.378 kb groß. Keine fpt. Die dazugehörige cdx hat gerade 1.533.661 kb groß.

Mir wird zuzugeber Maßen dabei auch etwas mulig. Das ist eine Protokolldatei, in die sekündlich neue Daten rein kommen. Und ich habe Pläne, die zu teilen - jedes Jahr eine eigen dbf, die dann jeweils gut 1 GB groß sein wird. Noch läuft das sauber. Aber Alaska ud Joachim sind sehr unterschiedlicher Meinung, wie groß die sein darf. Die Angaben schwanken von 2,4 GB (Alaska) und 16 GB (Joachim). Die erste Angabe ist natürlich falsch, da sind wir locker drüber und es hat nicht geknallt im System.

Jan

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 10:15
von brandelh
ist die Datei exclusive geöffnet ?

Evtl. ist dann der LOCK Offset (der ja das Hauptproblem darstellt) nicht nötig.
Oder du hast noch keinen Satz in die riesen Datei mit FOXCDX geschrieben, der nach 2,4 GB liegt.

Ich versuche es nochmal, es könnte auch mit der 2.00 was verbessert worden sein, was in der 1.90 noch nicht ging. Meine Tests sind schon Jahre her.

Bei FSEEK oder FSIZE wurde ja ein Fehler behoben, normale Dateien kann man mit den F-Funktionen jedenfalls deutlich über der 4 GB Grenze fehlerfrei bearbeiten.
Grundsätzlich geht es also sehr wohl mit 32 Bit Anwendungen Dateien über 4 GB zu nutzen, aber beim LOCK OFFSET ist die DBF in einer Zwickmühle, solange man kompatibel sein will.

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 10:19
von Jan
Hubert,

nein, kein exklusives öffnen. Da wird von nur einer Seite reingeschrieben, aber von verschiedenen gelesen. Und richtig, da wird nur über den ADS was reingeschrieben. Da die wie gesagt im propritären Zugriff ist, kommt man da halt nicht anders ran. Ich könnte aber mal testen, die aus dem ADS raus zu kopieren, und dann per FOXCDX dran zu arbeiten. Nur um zu sehen, ob das klappt (vermutlich ja wohl eher nicht).

Jan

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 10:52
von brandelh
Ich lasse gerade mal einen Test laufen:

Code: Alles auswählen

#include "Common.ch"
#include "foxdbe.ch"

PROCEDURE DbeSys()
  DbeLoad("FOXDBE")
  DbeSetDefault("FOXDBE")
RETURN

PROCEDURE Main
   LOCAL aStru := {}, x, cX

   SET CHARSET TO ANSI

   SET ALTERNATE TO test.txt
   SET ALTERNATE ON

   ?
   ? "Wie groß kann eine Standard FOXDBE DBF exclusive werden ?"
   ?
   ? "Start des Testes"

   * $TODO: place your application code here */

  AAdd( aStru , { "NAME"    ,"C", 50 ,  0 } )
  AAdd( aStru , { "Strasse" ,"C", 50 ,  0 } )
  AAdd( aStru , { "PLZ"     ,"C", 10 ,  0 } )
  AAdd( aStru , { "ORT"     ,"C", 50 ,  0 } )
  AAdd( aStru , { "CUST_ID" ,"N",  8 ,  0 } )

  DbCreate("TEST",aStru,"FOXDBE")
  USE TEST EXCLUSIVE

  x := 1

  DO WHILE .T.
     cX := str(x,18,0)
     DbAppend()
     FIELD->CUST_ID := x
     FIELD->NAME    := "Name   "+cX
     FIELD->STRASSE := "Strasse"+cX
     FIELD->ORT     := "Ort    "+cX
    //  dbcommit() // das bremst extrem
    IF right(cX,3)="000" .OR. x=1
        dbcommit() // das reicht völlig
        ? transform(x,"999,999,999,999,999,999"),trim(FIELD->NAME),transform(fsize("test.dbf"),"999,999,999,999,999,999")
        IF fsize("test.dbf") > 99999999999
           ? "Abbruch des erfolgreichen Tests !"
           ? transform(x,"999,999,999,999,999,999"),trim(FIELD->NAME),transform(fsize("test.dbf"),"999,999,999,999,999,999")
           exit
        ENDIF
     ENDIF
     x++

  ENDDO

  ? "Ende ohne Abbruch"

  SET ALTERNATE TO

  inkey(0)

RETURN
mal sehen was passiert ...

hier das Ergebnis:
Protokolldatei TEST.TXT endet so hat geschrieben: ...
12.705.000 Name 12705000 2.147.145.456
12.706.000 Name 12706000 2.147.314.456
12.707.000 Name 12707000 2.147.483.456
und das ist die XPPERROR.LOG
------------------------------------------------------------------------------
FEHLERPROTOKOLL von "C:\Users\BRANDELH\Documents\Xbase++\projects\BigDBF\BigDBF.exe" Datum: 23.06.2018 13:01:20

Xbase++ Version : Xbase++ (R) Version 2.00.951
Betriebssystem : Windows 7 06.01 Build 07601 Service Pack 1
------------------------------------------------------------------------------
oError:args :
oError:canDefault : J
oError:canRetry : J
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Interne Datenstrukturen beschädigt
oError:filename :
oError:genCode : 41
oError:operation : DbAppend
oError:osCode : 0
oError:severity : 2
oError:subCode : 5
oError:subSystem : BASE
oError:thread : 1
oError:tries : 1
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von MAIN(59)

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 11:11
von HaPe
Hallo Michael !
Nee, ich verwende gar keinen Treiber.
Ich spreche nicht von den Clients sondern vom Server.
Wie greift dein Server(-programm), welches in Xbase geschrieben ist, dann auf die "dbf oder ntx oder xpf oder cdx oder sonst welche Dateien zu"?

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 11:14
von ramses
Hallo Jan

Unter ADS gilt:
When using DBF tables over 4 GB in size, you must use Advantage Proprietary Locking.
und
Maximum table size: Windows with NTFS 16 exabytes (18,446,744,073,709,551,616 bytes)
Gruss Carlo

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 11:16
von HaPe
Hallo Jan !
Natürlich sehe ich auch das es einen Unterschied gibt, wenn die dbf unter der Fuchtel des ADS liegt. Aber der verändert an der dbf gar nichts.
Ok, dann ist das so.
Wenn an der Datenstruktur nichts geändert ist, kann der ADS-DBF-Treiber anders als Xbase, Clipper, Foxpro, ... DBF-Dateien verwalten die viel größer als 2 GB sind.

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 12:00
von mikehoffmann
Wie greift dein Server(-programm), welches in Xbase geschrieben ist, dann auf die "dbf oder ntx oder xpf oder cdx oder sonst welche Dateien zu"?
Auf der Client-Seite fange ich die 10 API-Calls ab, die das Xbase-Runtime-System vom Betriebssystem nutzt. Die Parameter der Calls schicke ich an den Server. Der macht dann genau diese Calls mit den abgefangenen Parametern und liefert das Ergebnis zurück an den Client. Die Parameter kommen übrigens als Array rein. Dafür sorgt mein Ratzfatz-Socket-Protokoll, das ausgiebig Var2Bin und Bin2Var nutzt. Eigentlich arschlangsam aber schnell implementiert. Die PassOn*-Methoden von fm leiten direkt an die API-Funktionen weiter. Ach ja, als Erstes bekommt dieser Handler die File-Handle, mit der er sich beschäftigen soll vom Client geschickt. Wenn beim Client die Datei geschlossen wird, wird auch der Verbindungssocket geschlossen und der Thread auf Serverseite dadurch automatisch beendet.

Hier der ganze Server Code, der im Moment je geöffnetem File in einem eigenen Thread tickt. Nur hingeschlunzt und ohne Kommentare.

Code: Alles auswählen

SECTION Instance Request handling

   STATIC FUNCTION InstanceSocketHandlerFunc(clientAddr,socket)

      LOCAL command
      LOCAL data,retData
      LOCAL fileHandle

      * No handle coming in? Let's die
      IF .NOT. ReceiveDataFromSocket(socket,@fileHandle)
         RETURN NIL
      ENDIF

      DebugMessage(SVI("Instance request connection established with client &1 and handle &2",clientAddr,fileHandle))

      DO WHILE ReceiveDataFromSocket(socket,@data)

         command := data[1]

         DO CASE

            CASE command == FMRI_CMD_READ
                 SendDataToSocket(socket,HandleRead(fileHandle,data))

            CASE command == FMRI_CMD_WRITE
                 SendDataToSocket(socket,HandleWrite(fileHandle,data))

            CASE command == FMRI_CMD_SETPOINTER
                 SendDataToSocket(socket,HandleSetPointer(fileHandle,data))

            CASE command == FMRI_CMD_CLOSE
                 SendDataToSocket(socket,HandleClose(@fileHandle,data))

            CASE command == FMRI_CMD_GETSIZE
                 SendDataToSocket(socket,HandleGetSize(fileHandle,data))

            CASE command == FMRI_CMD_LOCK
                 SendDataToSocket(socket,HandleLock(fileHandle,data))

            CASE command == FMRI_CMD_UNLOCK
                 SendDataToSocket(socket,HandleUnlock(fileHandle,data))

            CASE command == FMRI_CMD_SETEND
                 SendDataToSocket(socket,HandleSetEnd(fileHandle,data))

            OTHERWISE
                 SysError(SVI("Unknown command &1 received.",command))

         ENDCASE

      ENDDO

      socket:Close()

      IF ValType(fileHandle) == "N"
         fm:PassOnCloseHandle(fileHandle)
      ENDIF

      DebugMessage(SVI("Instance request connection with client &1 closed.",clientAddr))

   RETURN NIL


   STATIC FUNCTION HandleRead(fileHandle,data)

      LOCAL buffer := LockNullString(data[2])
      LOCAL lpBytesRead := LockNullString(4)
      LOCAL rc

      rc := fm:PassOnReadFile(fileHandle,buffer,data[2],lpBytesRead,0)

   RETURN {rc,Bin2L(UnlockString(lpBytesRead)),UnlockString(buffer)}



   STATIC FUNCTION HandleWrite(fileHandle,data)

      LOCAL lpBuffer := LockString(data[2],STRINGTYPE_BINARY)
      LOCAL lpNumberOfBytesWritten := LockNullString(4)
      LOCAL rc

      * Pass on to the O/S
      rc := fm:PassOnWriteFile(fileHandle,lpBuffer,data[3],lpNumberOfBytesWritten,0)

      * Release the buffer
      ReleaseLockString(lpBuffer)

   RETURN {rc,Bin2L(UnlockString(lpNumberOfBytesWritten))}



   STATIC FUNCTION HandleSetPointer(fileHandle,data)

   RETURN fm:PassOnSetFilePointer(fileHandle,data[2],0,data[3])



   STATIC FUNCTION HandleClose(fileHandle)

      LOCAL rc := fm:PassOnCloseHandle(fileHandle)

      filehandle := "Handle has already been closed!"

   RETURN rc



   STATIC FUNCTION HandleGetSize(fileHandle)

      LOCAL rc := fm:PassOnGetFileSize(fileHandle,0)

   RETURN rc



   STATIC FUNCTION HandleLock(fileHandle,data)

   RETURN fm:PassOnLockFile(fileHandle,data[2],0,data[3],0)



   STATIC FUNCTION HandleUnlock(fileHandle,data)

   RETURN fm:PassOnUnlockFile(fileHandle,data[2],0,data[3],0)



   STATIC FUNCTION HandleSetEnd(fileHandle)

   RETURN fm:PassOnSetEndOfFile(fileHandle)



ENDSECTION

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 12:43
von HaPe
Hallo Michael !
Auf der Client-Seite fange ich die 10 API-Calls ab, die das Xbase-Runtime-System vom Betriebssystem nutzt. Die Parameter der Calls schicke ich an den Server.
Das ist natürlich einerseits sehr Clever =D> (viel weniger Aufwand als selbst einen Datei-Treiber zu schreiben), andererseits bist du an die Möglichkeiten und Grenzen des Xbase-Datei-Treibers gebunden #-o
Ich frage mich nun ernsthaft welchen Vorteil du dir damit erhoffst, außer alles selbst in der Hand zu haben und kein separates Tool/Server-Programm kostenpflichtig erwerben und verwenden zu müssen :?:

Halt, einen wichtigen Punkt habe ich vergessen den du eventuell berücksichtigst: Deine bisherigen Programme müssen nicht oder nur minimal geändert werden. :blob8:
Mich würde mal interessieren, wen das außer mir noch alles betreffen würde oder ob Eure Programme schon alle brav auf SQL basieren.
Wie sind Eure Aussichten und Absichten, das in kurzer Zeit hinzukriegen? Wollt Ihr überhaupt noch?
Zu deiner Frage im ersten Thread: Ich stelle um auf $MS-SQL-Server bzw. PostGreSQL was einen ersten Schritt darstellt.
Was später passiert mit der Business-Logik und der UI steht bei mir noch nicht fest.
Da ich viel im technischen Bereich entwickle, benötige ich dafür keine Web-Oberflächen oder die Möglichkeit das Programm auf jeder Plattform ausführen zu müssen. Hier kommt es meist auf Geschwindigkeit an ...

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 13:08
von brandelh
mikehoffmann hat geschrieben: Sa, 23. Jun 2018 12:00
Wie greift dein Server(-programm), welches in Xbase geschrieben ist, dann auf die "dbf oder ntx oder xpf oder cdx oder sonst welche Dateien zu"?
Auf der Client-Seite fange ich die 10 API-Calls ab, die das Xbase-Runtime-System vom Betriebssystem nutzt.
Die Parameter der Calls schicke ich an den Server.
Der macht dann genau diese Calls mit den abgefangenen Parametern und liefert das Ergebnis zurück an den Client. Die Parameter kommen übrigens als Array rein.
sind das die Funktionen die du oben "ersetzt" hast ?

Woher weißt du was Xbase++ intern mit den Schreibzugriffen macht ?

Ich gebe zu, auf die Idee wäre ich nie gekommen. Hut ab.

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 13:14
von brandelh
Die maximale DBF Dateigröße die ich oben ermittelt habe, habe ich dort eingetragen.

Auch die FOXDBE exclusive ohne zusatz Eingaben bricht bei etwas über 2 GB ab.

viewtopic.php?f=20&t=10528&p=123105#p123105

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 13:38
von Tom
Ich frage mich nun ernsthaft welchen Vorteil du dir damit erhoffst,
Keine lokalen Dateizugriffe, also kein Protokollmist, keine Virenscanner, keine Probleme mit einschlafenden Verbindungen o.ä.
Wenige Codeänderungen.
Perspektivisch Performancegewinn.
Theoretisch erhöhte Datensicherheit, denn man könnte den Server kapseln. Man könnte sogar die Header manipulieren und den Zugriff von außen deutlich erschweren.
Datenzugriff auch über Web denkbar.

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 13:57
von HaPe
Hallo Tom !
Keine lokalen Dateizugriffe, also kein Protokollmist, keine Virenscanner, keine Probleme mit einschlafenden Verbindungen o.ä.
Wenige Codeänderungen.
Perspektivisch Performancegewinn.
Theoretisch erhöhte Datensicherheit, denn man könnte den Server kapseln. Man könnte sogar die Header manipulieren und den Zugriff von außen deutlich erschweren.
Datenzugriff auch über Web denkbar.
Fast alles kann man mit vorhandenen und erprobten kostenfreien wie kostenpflichtigen SQL-Servern von PostGreSQL, ADS, MySQL, MariaDB, FireBird, $MS, usw. auch erreichen.
Dazu muß man das Rad nicht neu erfinden :)

Um es auch wirklich deutlich auszudrücken, ich finde es genial was Michael so alles macht. =D>
Bei manchen Projekten erschließt sich mir allerdings der Sinn bzw. der Antrieb dazu nicht da es dafür schon andere und auch insgesamt bessere Lösungen gibt. :idea:

Deshalb von mir die Frage nach dem Warum :D

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 14:07
von mikehoffmann
Erst mal vorne weg: Das war nur ein Versuch, ob es geht, ob meine Einschätzung des geringen Aufwands korrekt ist und wie's mit der Performance ungefähr aussehen wird. Da kann man noch viel optimieren.

@HaPe:
Das ist natürlich einerseits sehr Clever =D> (viel weniger Aufwand als selbst einen Datei-Treiber zu schreiben), andererseits bist du an die Möglichkeiten und Grenzen des Xbase-Datei-Treibers gebunden
Es ging nicht darum, einen SQL-Ersatz zu schaffen oder einen neuen Treiber zu schreiben. Ich wollte nur ohne SMBx auskommen. Das ist zu 100% gelungen. Den Server könnte man auch in C++ implementieren. Das wäre marginal mehr Code und schon könnte man das Ding auf anderen Betriebssystemen laufen lassen, wenn man sich von Windows als Server abwenden möchte. Ich seh's kommen, dass ich irgendwann doch noch einen Xbase++ to C++ Transpiler schreiben muss. Dass ich alles selber in der Hand habe, ist ein schöner Nebeneffekt. Außerdem kommt man ohne den Server und die zugreifende Applikation nicht mehr an die Daten ran. Keine Explorer-User-Katastophen mehr möglich. Da fallen mir noch eine Menge Dinge mehr ein, die man machen könnte im Bereich Server-Überwachung und Zugriffs-Protokollierung.

@Hubert:
sind das die Funktionen die du oben "ersetzt" hast ?
Ich ersetze nicht, ich leite um, wenn ich zuständig bin. Meine Zuständigkeit erkenne ich durch das "\\DBFSVR\" im Pfad, wenn die Datei geöffnet wird.
Der Eingriff erfolgt zwischen den xbase dlls und kernel32.dll. Da sitze ich schon länger erfolgreich drin, um die üblichen Virenschutzprobleme abzuwenden und auch um z.B. Daten zu verschlüssen. Deswegen musste ich ja eigentlich nur noch die Netzwerkumleitung der Calls implementieren und die Problemgröße war einschätzbar.
Woher weißt du was Xbase++ intern mit den Schreibzugriffen macht ?
Zum Schreiben in eine Datei gibt es zwei Funktionen in der kernel32.dll: WriteFile und WriteFileEx. Nur die kann Xbase nutzen und dauch da klinke ich mich einfach ein. Daten im Browse ändern geht z.B. einwandfrei. Nachdem ich vorher SET EXCLUSIVE ON gemacht habe, natürlich.

Oder habe ich Dich falsch verstanden?

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 14:20
von Tom
Hallo, HaPe.

Ohne drastische Codeänderungen nutzen Dir die ganzen SQL-Server nix. Außerdem war das nur ein Aspekt.

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 16:08
von brandelh
mikehoffmann hat geschrieben: Sa, 23. Jun 2018 14:07 Erst mal vorne weg: Das war nur ein Versuch, ob es geht, ob meine Einschätzung des geringen Aufwands korrekt ist und wie's mit der Performance ungefähr aussehen wird. Da kann man noch viel optimieren.
...
Der Eingriff erfolgt zwischen den xbase dlls und kernel32.dll. Da sitze ich schon länger erfolgreich drin, um die üblichen Virenschutzprobleme abzuwenden und auch um z.B. Daten zu verschlüssen.
Deswegen musste ich ja eigentlich nur noch die Netzwerkumleitung der Calls implementieren und die Problemgröße war einschätzbar.
Woher weißt du was Xbase++ intern mit den Schreibzugriffen macht ?
Zum Schreiben in eine Datei gibt es zwei Funktionen in der kernel32.dll: WriteFile und WriteFileEx.
Nur die kann Xbase nutzen und dauch da klinke ich mich einfach ein. Daten im Browse ändern geht z.B. einwandfrei.
Nachdem ich vorher SET EXCLUSIVE ON gemacht habe, natürlich.
Ich sage ja, du machst Sachen, die weit jenseits der Xbase++ Entwickler liegen.
Wie du dich zwischen die Runtime DLL und das OS geschaltet hast, ist nicht trivial - für einen Xbase++ Anwendungs Entwickler !

Genau das sind aber die meisten die hier mitlesen - inkl. mir.

In der Schule haben Sie uns beigebracht wie man Indexdateien für Datendateien erstellt.
Ich war in einer der ersten Wirtschaftsschulen / Wirtschaftsgymnasium die EDV unterrichtet haben, bin dann aber in den öffentlichen Dienst und habe nicht Informatik studiert.
Der erste Vorteil von Clipper war, dass ich mich weder um Datenstrukturen noch um Indexdateien kümmern brauchte und auch mehrere gleichzeitige Zugriffe auf die neuen OS/2 Server wunderbar funktioniert haben.
Ich wollte Anwendungen schreiben, die den Menschen die Arbeit erleichtern und kein Betriebssystem neu erfinden ;-)

Wenn es dir nützt und du damit deine Arbeit leichter und sicherer erledigen kannst, super !
Und nochmal Hut ab für die Umsetzung.

Ich würde dennoch immer einen allgemein erprobten Weg gehen und wenn ich die Notwendigkeit hätte
noch Anwendungen im Netz zu schreiben würde ich einen SQL Server mit SQLexpress oder den API Klassen vorziehen.

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 16:41
von Tom
Wir haben hunderte Kunden, die die gleiche Anwendung mit nativem DBF-Zugriff, ADS und PGDBE (kleinster Teil, wachsend) nutzen. Vielen ist völlig wurscht, wie wir Daten halten, sie wollen es unkompliziert - und scheuen Investitionen. Gleichzeitig muss sich unsere Supportfront immer wieder mit schlimmen Virenscannern, sich dynamisch verändernden Betriebsssytemsituationen, krasser Hardware und originellen WLAN-Topologien herumschlagen, obwohl das eigentlich nicht unser Servicebereich ist ("Aber Office läuft schnell und fehlerfrei!"). Insofern wäre da eine Hybrid-Serverlösung nicht ganz uninteressant. Wir würden es ja gerne so haben, dass bei allen das gleiche wäre, aber wie sagte schon der große, weise Lothar Matthäus? "Wäre, wäre, Fahrradkette." Stimmt. 8)

Re: SMB1 und Dateizugriff-Schweinkram

Verfasst: Sa, 23. Jun 2018 18:31
von brandelh
Tom hat geschrieben: Sa, 23. Jun 2018 16:41 Wir haben hunderte Kunden, die die gleiche Anwendung mit nativem DBF-Zugriff, ADS und PGDBE (kleinster Teil, wachsend) nutzen. Vielen ist völlig wurscht, wie wir Daten halten,
und das ist gut für die, denn Ihr wisst was ihr tut.

Aber ich habe kurz nach 2000 erlebt, dass eine meiner Anwendungen von einer Schwester Verwaltung abgelehnt wurde,
weil deren EDV Mann meinte Dbase wäre völlig veraltet (wie gesagt, Xbase++ EXE, aber DBF = DBASE ... und er konnte das blocken).
Wir wollten nix für die Anwendung und die läuft bei uns mittlerweile (zuerst Clipper, dann Xbase++) seit über 20 Jahren.