SMB1 und Dateizugriff-Schweinkram
Moderator: Moderatoren
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
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
Zugegebenermaßen liegt die in einem ADS. Aber trotzdem, es geht.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: SMB1 und Dateizugriff-Schweinkram
Hallo Jan !
Wenn Michael natürlich seinen eigenen DBF-Treiber für den Server verwendet und nicht den von Xbase ist alles gut
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.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.
Wenn Michael natürlich seinen eigenen DBF-Treiber für den Server verwendet und nicht den von Xbase ist alles gut
--
Hans-Peter
Hans-Peter
- mikehoffmann
- Rekursionen-Architekt
- Beiträge: 136
- Registriert: Mo, 21. Sep 2015 16:22
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 19 Mal
Re: SMB1 und Dateizugriff-Schweinkram
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.
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- mikehoffmann
- Rekursionen-Architekt
- Beiträge: 136
- Registriert: Mo, 21. Sep 2015 16:22
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 19 Mal
Re: SMB1 und Dateizugriff-Schweinkram
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.und wo ist die maximal Grösse der Datenbank?
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
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
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
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
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:
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
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 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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
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.
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.
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
Ich lasse gerade mal einen Test laufen:
mal sehen was passiert ...
hier das Ergebnis:
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
hier das Ergebnis:
und das ist die XPPERROR.LOGProtokolldatei 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
------------------------------------------------------------------------------
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)
Gruß
Hubert
Hubert
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: SMB1 und Dateizugriff-Schweinkram
Hallo Michael !
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"?
Ich spreche nicht von den Clients sondern vom Server.Nee, ich verwende gar keinen Treiber.
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"?
--
Hans-Peter
Hans-Peter
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: SMB1 und Dateizugriff-Schweinkram
Hallo Jan
Unter ADS gilt:
Unter ADS gilt:
undWhen using DBF tables over 4 GB in size, you must use Advantage Proprietary Locking.
Gruss CarloMaximum table size: Windows with NTFS 16 exabytes (18,446,744,073,709,551,616 bytes)
Zuletzt geändert von ramses am Sa, 23. Jun 2018 11:16, insgesamt 1-mal geändert.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: SMB1 und Dateizugriff-Schweinkram
Hallo Jan !
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.
Ok, dann ist das so.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.
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.
--
Hans-Peter
Hans-Peter
- mikehoffmann
- Rekursionen-Architekt
- Beiträge: 136
- Registriert: Mo, 21. Sep 2015 16:22
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 19 Mal
Re: SMB1 und Dateizugriff-Schweinkram
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.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"?
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
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: SMB1 und Dateizugriff-Schweinkram
Hallo Michael !
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.
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 ...
Das ist natürlich einerseits sehr Clever (viel weniger Aufwand als selbst einen Datei-Treiber zu schreiben), andererseits bist du an die Möglichkeiten und Grenzen des Xbase-Datei-Treibers gebundenAuf 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.
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.
Zu deiner Frage im ersten Thread: Ich stelle um auf $MS-SQL-Server bzw. PostGreSQL was einen ersten Schritt darstellt.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?
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 ...
--
Hans-Peter
Hans-Peter
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
sind das die Funktionen die du oben "ersetzt" hast ?mikehoffmann hat geschrieben: ↑Sa, 23. Jun 2018 12:00Auf der Client-Seite fange ich die 10 API-Calls ab, die das Xbase-Runtime-System vom Betriebssystem nutzt.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"?
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.
Woher weißt du was Xbase++ intern mit den Schreibzugriffen macht ?
Ich gebe zu, auf die Idee wäre ich nie gekommen. Hut ab.
Gruß
Hubert
Hubert
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
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
Auch die FOXDBE exclusive ohne zusatz Eingaben bricht bei etwas über 2 GB ab.
viewtopic.php?f=20&t=10528&p=123105#p123105
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 105 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
Keine lokalen Dateizugriffe, also kein Protokollmist, keine Virenscanner, keine Probleme mit einschlafenden Verbindungen o.ä.Ich frage mich nun ernsthaft welchen Vorteil du dir damit erhoffst,
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.
Herzlich,
Tom
Tom
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: SMB1 und Dateizugriff-Schweinkram
Hallo Tom !
Dazu muß man das Rad nicht neu erfinden
Um es auch wirklich deutlich auszudrücken, ich finde es genial was Michael so alles macht.
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.
Deshalb von mir die Frage nach dem Warum
Fast alles kann man mit vorhandenen und erprobten kostenfreien wie kostenpflichtigen SQL-Servern von PostGreSQL, ADS, MySQL, MariaDB, FireBird, $MS, usw. auch erreichen.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.
Dazu muß man das Rad nicht neu erfinden
Um es auch wirklich deutlich auszudrücken, ich finde es genial was Michael so alles macht.
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.
Deshalb von mir die Frage nach dem Warum
--
Hans-Peter
Hans-Peter
- mikehoffmann
- Rekursionen-Architekt
- Beiträge: 136
- Registriert: Mo, 21. Sep 2015 16:22
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 19 Mal
Re: SMB1 und Dateizugriff-Schweinkram
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:
@Hubert:
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.
Oder habe ich Dich falsch verstanden?
@HaPe:
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.Das ist natürlich einerseits sehr Clever (viel weniger Aufwand als selbst einen Datei-Treiber zu schreiben), andererseits bist du an die Möglichkeiten und Grenzen des Xbase-Datei-Treibers gebunden
@Hubert:
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.sind das die Funktionen die du oben "ersetzt" hast ?
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.
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.Woher weißt du was Xbase++ intern mit den Schreibzugriffen macht ?
Oder habe ich Dich falsch verstanden?
Zuletzt geändert von mikehoffmann am Sa, 23. Jun 2018 14:27, insgesamt 1-mal geändert.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 105 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
Hallo, HaPe.
Ohne drastische Codeänderungen nutzen Dir die ganzen SQL-Server nix. Außerdem war das nur ein Aspekt.
Ohne drastische Codeänderungen nutzen Dir die ganzen SQL-Server nix. Außerdem war das nur ein Aspekt.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
Ich sage ja, du machst Sachen, die weit jenseits der Xbase++ Entwickler liegen.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.Zum Schreiben in eine Datei gibt es zwei Funktionen in der kernel32.dll: WriteFile und WriteFileEx.Woher weißt du was Xbase++ intern mit den Schreibzugriffen macht ?
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.
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.
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 105 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
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.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
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.
Gruß
Hubert
Hubert