SMB1 und Dateizugriff-Schweinkram

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann »

Liebe Xbase-Kollegen,

ob das langsame Directory() am SMB1 liegt, weiss ich nicht. Ich tippe eher nein. Aber Microsoft wird SMB1 auf Dauer kippen. Da unsere dbf/??x-Programme wohl mit den neueren SMB-Versionen nicht so recht funktionieren, könnte uns das ganz schön kneifen. 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?

Woran es genau liegt mit den SMB-Versionen, ist für mich auch noch im Dunklen. Ich weiß aber, dass unsere dbf/??x-Zugriffe eigentlich schweinkrammäßig implementiert wurden, damit man vernünftig gemeinsam auf die Daten zugreifen kann. So wird, um einen Satz zu sperren, ein Byte in der Datei gesperrt, das es gar nicht gibt, und dann ganz woanders in der Datei gelesen und geschrieben. Das scheint uns nun einzuholen. Windows hat viele Probleme, gerade weil es rückwärtskompatibel ist und so z.B. dieser Schweinkram auch nach 30 Jahren noch funktioniert. Da den Stecker mal zu ziehen, kann ich gut verstehen.

Wenn ich die Wahl habe, meine Programme, die z.T. in der Maschinensteuerung verwendet werden, nun entweder auf SQL umzustellen oder selber eine kleine Server-Applikation zu schreiben, die die Dateizugriffe und Locks meiner Xbase++-Programme bedient und die Sperrungen anständig behandelt, dann würde ich Zweiteres zunächst mal ausprobieren wollen. Um es klarzustellen: Die Abstraktion von Betriebssystem-Datei auf Workarea würde weiter im Client passieren, nur die Betriebssystem-Datei-API-Calls würden an die Server-Anwendung weitergereicht, die sie dann fast 1:1 an das Betriebssystem des Rechners weitergibt, auf dem sie tickt. Mit den Locks kann man sich Gedanken machen, wie man das besser implementiert. Aber man kann aus den Parametern der Lock-Calls sehr gut ablesen, was der Client gerade vorhat und das auf dem Server synchronisieren. Mit Pufferung der Calls zwischen einen BEGIN TRANSACTION und END TRANSACTION könnte man vielleicht sogar Transaktionen implementieren.

In der Praxis müsste man auf dem Server-Rechner eine Applikation starten und in der Client-Applikation die Verbindung zu dieser Server-Applikation aufbauen und die Calls umlenken. Easy-Peasy. Blöde wird's mit Tools wie R&R, die direkt selber auf die dbfs losgehen, aber da müsste man mit dll-injection auch klarkommen. Oder auf andere Tools umstellen, z.B. L&L.

Ich bitte um Kommentare, ob Euch so ein Weg gangbar erscheint oder man doch lieber gleich Mainstream SQL anstreben sollte.

Viele Grüße
Michael
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Martin Altmann »

Moin Michael,
Phil Ide und Jack Duijf sind genau den von Dir vorgeschlagenen DBF-Server-Weg damals gegangen und bieten das auf ihrer Homepage zum Download an.
Darauf könntest Du ja ggf. aufsetzen?

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von brandelh »

Ich habe mal eben beim NAS SMB1 abgeschaltet und von SMB2 bis SMB3 freigegeben, mein Client ist Win 7 Pro ...

- dann wird (auch laut MS Info) auch kein Rechner mehr gefunden (unter Netzwerke)
- der Zugriff auf \\NAS (also richtigem Namen, keine Suche) schlägt aber auch fehl.
- Active Directory habe ich hier nicht und der Rest sagt mir nix.
- Einen eigenen TCPIP Server zu generieren, der zuverlässig arbeitet ist nicht ohne ... meine Test mit den Sockets waren ernüchternd, aber das ist ja auch schon Jahre her.
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Jan »

Hallo Michael,

bislang habe ich weder meine eigenen Programme noch die von Kunden nach SQL umgeschrieben. Das hat verschiedene Gründe.

Klar, der Aufwand, bestehende Software umzuschreiben. Aber auch, das zumindest Privatleute eher keinen ausgewachsenen SQL-Server installieren und warten möchten. Da haben wir allerdings im vergangenen Jahr einen interessanten Ansatz auf unserem XUG-Treffen diskutiert. Vielleicht war auch bislang einfach der Leidensdruck noch nicht groß genug ;-)

Bei einem Kunden haben wir das Problem etwas verlagert, indem wir da weiterhin mit dbf arbeiten, die aber mit proprietärem Zugriff in einen ADS geschoben haben. Neben den Zugriffsproblemen hat das gleich noch einen Schwung anderer Probleme gelöst (Datenschutz, etc.)

Ob ich den Alaska-PostgreSQL-DB-Funktionen-Weg gehen möchte? Im Moment eher wohl nicht. Aber wer weiß was die Zukunft so bringen wird. Angeschaut hatte ich mir das schon mal. Und dann eine böse Diskussion mit Alaska gehabt. Die stehen auf dem Standpunkt, die Konvertierung der Daten von dbf->SQL ginge automatisch. Was in meinen Augen nichts stimmt. Ich seh da den Gesamtprozess, Alaska nur den ab den manuellen Vorarbeiten (Erstellen der Konfigurationsdateien, etc.). Wenn man dann Andreas im Support als Gesprächspartner hat, dann kann man sowieso gleich aufgeben.

Das hängt natürlich auch davon ab, was MS noch so für Überraschungen für uns auf Lager hat. Wer weiß schon, wie die ihr SMB weiterentwickeln werden. Oder mit dateibasierten Daten umgehen werden in der Zukunft. Dabei geht es ja nicht nur um dbf, sondern auch um eine Vielzahl anderer Formate.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Martin Altmann »

Hier mal der link zu dem Repository: http://www.idep.nl/xbase/datpage/dbfserver.html

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von brandelh »

Was für mich nicht klar ist, wenn SMB2 eingestellt ist, geht dann ...

- Net Use X: \\freigabe ... und use x:\pfad\dbfname ?
- use \\freigabe\pfad\dbfname ...
- directory() ?

ich habe das hier nicht hinbekommen, aber ich bin auch nicht mehr auf dem laufenden was M$ Produkte angeht.

ich bin schon ernüchtert, dass das normale Browsen von Dateien im Windows Explorer nicht geht ... gerade für kleine Firmen und Privat Leute, die haben doch kein Active Directory

M$ ist übrigens sehr eindeutig: !!! DON'T USE SMB1 !!! DON'T SHARE FILES !!!

Sind gesharte Dateien auf reinem SMB2 / SMB3 grundsätzlich möglich (ohne Xbase++ etc.) ?
Gruß
Hubert
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann »

DbfServer: Ich erinnere mich an den Server. Der hat aber auf Workarea/Feldebene getickt. Das heißt, die DBFs waren als Workareas auf dem Server geöffnet und jeder Feldzugriff wurde über das Netz geschickt. Leider turbolangsam (außer bei Filtern, natürlich). Und jedesmal mit Makros oder Codeblöcken. Bei meinem Vorschlag würden die Client-Xbase-Runtime-API-Calls Öffnen, Lesen, Schreiben, Suchen, Dateizeiger Verschieben, Schließen, Sperren, ... nicht direkt beim Betriebssystem ankommen, sondern an den Server geschickt werden. Der führt dann die Calls bei sich aus und schickt das Ergebnis zurück. Das ist immer eine Portion platter Daten und ein Error-Code. Total simpel. Der Netzwerkverkehr würde sogar weniger werden als mit Netbios/SMBx. Vielleicht sollte man sich den Server als ein NAS-System vorstellen. Das Protokoll ist halt proprietär. Aber das wäre so einfach, dass man den Server auch ratz-fatz auf anderen Betriebssystemen implementieren könnte.
--- Michael, hör das Träumen auf! ---

Die Dateien würde man auf O/S-Ebene auf dem Client gar nicht sehen. Dufte für Datenschutzfreunde.

ADS: Ja, durchaus vergleichbar. Nur ohne den SQL-Teil und ohne speziellen Datenbanktreiber. Und ohne Query-Optimierung auf dem Server, weil auf Dateiebene tickend. Zumindest am Anfang.

Socket-Verbindungen: Ich habe schon einige TCP/IP (und UDP) Clients und Server geschrieben. Kein Problem. Das Einzige, womit ich nicht so richtig glücklich bin, ist die Fehlerbehandlung, wenn so eine Verbindung mal abreißt. Da wäre ich als moderne Applikation schon gerne über den Stand der Dinge informiert, sobald da etwas schief zu gehen beginnt. Aber da gibt's bestimmt ein paar Tricks, die ich noch nicht kenne.

Meine persönlichen Sorgen beginnen tatsächlich eher beim R&R, den ich schon länger über die Planke gehen lassen möchte, aber zeitbedingt (wie immer...) noch nicht ersetzen konnte. dll injection ist machbar, aber da habe ich verdammt wenig Erfahrung.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von AUGE_OHR »

moin,

mit Db-Server habe ich auch schon mal gespielt ...

ähnlich der Idee von Mike sehe ich das Problem darin das die Syntax nicht kompatibel ist mit "bestehenden" xBase (alle Versionen) Code den man hat.

was wir benötigen ist eine DBE mit der wir eine richtige Datenbank statt DBF nutzen können :!:

MySQL oder PostgreSQL wären richtige Datenbanken.
Alaska gibt uns zwar PgDBE aber die ISAM Emulation ist IMHO "misslungen" #-o

nun gibt es Xbase++ Wrapper die native auf solche "free" SQL Datenbanken zugreifen können die auch im Einsatz sind.
die Wrapper von Pablo sind nur für den Zugriff auf die DLL Dateien. "Regeln" oder eine ISAM Emulation fehlen da.
es gibt zwar verschiedene funktionierende Konzepte aber alle nicht als DBE sondern wie der Db-Server als CLASS

für mich wäre die Frage : wie bekommen wir eine API von Alaska um eine DBE zu schreiben :?:
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Tom »

Mit Verlaub, aber von einigen Kleinigkeiten und etwas mehr nötiger Vorarbeit abgesehen funktioniert die PG-ISAM-Sache nach meinem Dafürhalten recht gut. Kann es sein, dass das keiner von Euch ernsthaft ausprobiert hat?
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses »

Hallo Michael

ich verwende als Server aus vielen Gründen schon mehrere Jahre FreeBSD. Darauf ist Samba 4.7.x OHNE AD installiert. Als minimal Protokoll ist SMB3 vorgegeben. Auf Windows PC's kann ein normales Laufwerkmapping mit "Netzlaufwerk verbinden" ausgeführt werden. xbase Programme laufen mit der normalen DBFDBE ohne Anpassungen absolut Problemlos. Beachten muss man lediglich die korrekte Konfiguration und Anwendung bezüglich Klein/Grossschrift der Filenamen. Auf den PC's sind 4 Registery bezüglich File-Caching nötig.

Filesharing im Office ist problemlos und fehlerfrei. Auch der Explorer arbeitet mit Ordnern mit über 30'000 Dateien zügig. Nichts zu beanstanden.

Viele Xbase-Programme habe ich auch schon auf Web-Apps und nativem Postgres umgestellt was Geschwindigkeitsmässig jede DBE inkl. ADS bei weitem übertrifft. Lediglich die Alaska Postgres DBE ist auch hier völlig nutzlos bezw. unbenutzbar. Bereits das öffnen einer Datenbank kann schon Minuten in Anspruch nehmen.... Postgres kennt keine Recordnummern solange man auf diese für goto Befehle angewieen ist gibt es keine schnelle Lösung.

Auch eine Web-App mit XB2Net + L&L mit Xbase erstellt läuft auf einem FreeBSD Server einwandfrei, stabil und sorglos.

Ich sehe die Zukunft bei Web-Apps. Windows wird sich dahin so entwickeln dass es noch zum start eines Browser gut ist um darin eine Web App zu starten. Alles wesentliche läuft auf auf einem Server und die Desktop-Apps mit all den Problemen verschwinden. Effekte lassen sich ja jetzt schon viel einfacher mit JQuery Modulen Programmieren als mit den Xbase-Parts.

Auch wenn mit Windows neue Probleme kommen, werden meine Web-Apps auf dem Freebsd-Server noch lange Problemlos weiterlaufen. ......


Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von brandelh »

ramses hat geschrieben: Sa, 16. Jun 2018 14:14 Darauf ist Samba 4.7.x OHNE AD installiert.
Als minimal Protokoll ist SMB3 vorgegeben.
Auf Windows PC's kann ein normales Laufwerkmapping mit "Netzlaufwerk verbinden" ausgeführt werden.
xbase Programme laufen mit der normalen DBFDBE ohne Anpassungen absolut Problemlos.
Vielen Dank für diese Info :!: :!: :!:

Sie bestätigt meine Meinung (die ich bis heute nicht belegen konnte),
dass die Windows API die zugrunde liegende SMB Version "ausbügelt" ...

Ich habe auf meiner NAS SMB1 deaktiviert und auf meinem Laptop (Win 7 home) eben mit
net use das Laufwerk zugeordnet und anzeigen können:

net use o: \\NAS\Informationen

Nun starte ich das Programm von meinem Laptop auf der NAS:

\\Nas\prog_hb\HAUSHALT\HAUSPLAN.EXE

Das Programm startet, obwohl die NAS KEIN SMB1 laufen hat :!:
Meine Xbase++ EXE startet und ich habe den Eindruck, dass die Daten viel schneller geliefert werden als vorher :!:
Was nicht funktioniert ist die Anzeige des freien Speichers.
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von AUGE_OHR »

brandelh hat geschrieben: Sa, 16. Jun 2018 20:36 net use o: \\NAS\Informationen
\\Nas\prog_hb\HAUSHALT\HAUSPLAN.EXE
und was passiert wenn du einen 2nd User das selbe machen lässt ?

ich habe in meinem *.LNK es so

Code: Alles auswählen

\\192.168.xxx.yyy\MeineFreigabe\MyApp.EXE
ein NET USE ist damit NICHT notwendig und trotzdem kann die App auf Dateien "in dem" Ordner zugreifen ... das ist SMB2 :!:
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von AUGE_OHR »

Tom hat geschrieben: Sa, 16. Jun 2018 10:50 Mit Verlaub, aber von einigen Kleinigkeiten und etwas mehr nötiger Vorarbeit abgesehen funktioniert die PG-ISAM-Sache nach meinem Dafürhalten recht gut. Kann es sein, dass das keiner von Euch ernsthaft ausprobiert hat?
es kommt darauf an wie man "Ernsthaft" definiert ...

die Erwartungshaltung ist doch das ein Wechsel einer DBE ohne Probleme und Performance Verlust passiert.
Das ist in der Praxis NICHT der Fall was wohl die meisten User die es probiert haben feststellen mussten.

wenn man nun eine neue App entwickelt und sich strikt an das Konzept von Alaska hält UND SQL Kenntnisse hat DANN kann man auch PgDBE nutzen.
alternative kann man aber sich auch selbst eine native Schnittstelle bauen ... und die wäre dann auch nicht abhängig von Alaska

wer also mit dem Db-Server Code klar kommt wird auch mit MySQL / PostgreSQL CLASS Code keine grossen Probleme haben.

---

es gibt ja MySQL und PostgreSQL Wrapper ... aber wohl keine CLASS die beides kann, oder :?:
wie wäre es mit einem Forum Project :idea: man könnte das als Open Source Project bei GitHub machen.
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses »

Hallo Jimmy
kann man auch PgDBE nutzen
Solche Träume hatte ich auch schon.

Nein, kann man nicht! Die ist unbenutzbar. Sie erfordert einen alten Postgres Server mit den aktuellen gibts Fehler und das schlimmste ein USE auf eine grosse Datenbank dauert mehrere Minuten ----> unbenutzbar!!!!

Gruss Carlo
Valar Morghulis

Gruss Carlo
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von georg »

Hallo, Michael -


Du beschreibst das Problem sehr gut und treffend: wir operieren oft noch mit Programm-Strukturen und Befehlen, die aus der DOS-Zeit stammen und damals doch schon funktioniert haben.

Wenn wir dann umsteigen wollen, erwarten wir, dass jeder neue Ansatz den alten Strukturen entspricht und diese auch 1:1 abbilden kann. Man nennt das Rückwärtskompatibilität. Aber von dieser Idee muss man sich trennen, wenn man wirklich neues nutzen will.

Über pgDBE will ich nicht viel sagen, es wurden ausreichende Argumente gegen deren Einsatz gebracht.

Ich verwende seit Jahren den API-Wrapper von Hector Peroza, mit dem man sehr fein auf MySQL-Datenbanken zugreifen kann. Die Struktur der Programme verändert sich, da man klassenorientiert auf die Daten zugreift und nicht mehr per dbSeek(). Und damit verlagert man viel Probleme der DBF-Behandlung zum MySQL-Server.

Aber: Aufwand muss sein.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von brandelh »

Ich sehe das genauso :D
Gruß
Hubert
Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 831
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von satmax »

Auch auf die Gefahr hin gesteinigt zu werden gebe ich auch noch meinen Senf dazu. :wink:

Vor ein paar Jahren habe ich mein letzes Clipper Projekt auf Windows umgestellt, mit Xbase++ und SQL Express, GOTTSEIDANK! Als SQL Server verwenden wir MS SQL Express (kann sich jeder gratis laden) aber auch den MS SQL Server Vollversion, je nach Datenbankgröße. Datenbankfehler oder Reindex gibt es nicht mehr. Ich musste den Schritt mit SQL machen da wir auch mit C++ und SQL programmieren und teilweise auf die gleichen Daten zugreifen.

Heute habe ich den riesigen Vorteil, dank SQL, auch mit anderen Programmiersprachen arbeiten zu können. Vor ca. 2 Jahren habe ich begonnen mit Windev zu arbeiten. Das ganze war nach einem Jahr so erfolgreich das wir (2 Mann) seither alle Neuentwicklungen unter Windev/Windev Mobile und Webdev machen. Die Datenbank ist ja kompatibel, dank SQL!

Ganz wichtig bei SQL ist die Möglichkeit der Triggerprogrammierung, so kann man garantiert verhindern das eines der Programme etwas in die Datenbank schreibt und dabei ein Feld nicht richtig befüllt, genau so wie die Abhängigkeiten der einzelnen Tabellen zueinander, Transaktionen usw.

Wer heute noch mit einer Dateibasierenden Datenbank wie DBF arbeitet handelt meiner Meinung nach schon sehr fahrlässig, wenn nicht sogar grob fa...

Wie gesagt, meine Meinung.

Gruß
Markus
Gruß
Markus
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses »

Hallo Markus

Hut ab!

In etwa meine Worte. Mit WebDev hast du dann auch Web-Apps die Plattformunabhängig arbeiten.....

2008 forderte ein erster Kunde dass die Datenbank SQL fähig sein müsse, damals konnte das noch wegdiskutiert werden
Gottseidank habe ich einige Zeit später begonnen das ganze auf Web-Apps und Postges SQL umzustellen.
Wäre nicht so viel NowHow im Source Code hätte ich wie du die Plattform gewechselt.

Bei jungen Entscheidungsträgern lässt sich heute nur sehr schwer eine Desktop App einbringen, Sie sind mit Mobilen Diensten die sich überall nutzen lassen aufgewachsen und wollen dies nun auch im Geschäftsleben so haben .....

Apps wie wir Sie auch noch mit den Xbase-Parts erstellen/erstellten haben keine Zukunft!
Grundlage muss SQL sein und die Programme müssen Serverbasierend und mit beliebigen Endgeräten ohne Installation sofort nutzbar sein.
Der Zwang zu IIS oder Apache bezw. WAA ist ein NO GO.

Dies ist meine Meinung!

Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann »

Bei der Vielzahl und Vielfalt der Antworten wird’s schwer für mich, wieder zu bündeln.

@Jimmy:
„was wir benötigen ist eine DBE mit der wir eine richtige Datenbank statt DBF nutzen können“
Eine Datenbanktabelle wie eine DBF zu nutzen, könnte man näherungsweise hinbekommen, käme aber einer Vergewaltigung gleich. Deswegen ja auch die verschiedenen Rückmeldungen zum PgDB-Treiber. Für mich ist diese Idee ein Marketing-Gag.
„für mich wäre die Frage : wie bekommen wir eine API von Alaska um eine DBE zu schreiben“
Frag halt mal. Aber ich sehe da nicht wirklich einen Weg.

@Ramses / Carlo: (Free-BSD und Samba)
Roger that. Scheint wohl zu klappen, weil Samba/BSD nicht versucht, weiter zu optimieren, wie unsere Freunde aus dem Bundesstaat Washington es tun. Nur eine Vermutung. Deswegen das zum Server zu machen, überzeugt mich nicht.

@Hubert: Wir wissen doch eigentlich gar nicht, warum es mit irgendeinem SMB zufälligerweise bei bestimmten Registry-Einstellungen funktioniert. Das nervt mich. Außerdem werden dabei Optimierungen ausgehebelt. Deswegen will ich ja die Zugriffe wieder in die eigene Hand nehmen und der Eingriff erscheint mit auf O/S-Dateiebene am einfachsten.

@Georg: Ja, so isses. Ich habe jede Menge alten Code, der auf der Workarea-Welle mit DBFs reitet. Da hätte ich schon gerne, dass ich nicht viel rumändern muss und das Zeug auch in 20 Jahren noch sicher läuft. Außerdem bin ich der Meinung, dass eine SQL-Datenbank eben nicht für alles zu verwenden ist. DBF oder zumindest diese Art des Dateizugiffs hat weiter eine Daseinsberechtigung. Natürlich nicht unbedingt in Web-Apps.

@Satmax/Markus: Wenn das Fehlen eines Protokolls als fahrlässig zu bezeichnen ist, dann hast Du Recht. Dem kann man aber abhelfen. Wenn bei mir jedoch ein Maschinchen seinen Status immer an die gleiche Stelle in einer DBF-Tabelle schreibt oder 1000e von Protokollsätzen in eine für die Maschine exklusiv zugängliche DBF-Tabelle gewammst werden, dann finde ich das schon ziemlich optimal. Einen Flaschenhals SQL-Server möchte ich hier nicht haben. Und mit WinDev eine Anwendung zu zimmern, die Events von einer Maschine fast real-time verarbeiten muss, könnte auch spannend werden. Aber ist vielleicht auch nicht ausgeschlossen. Ich gebe Dir aber Recht, viele der Daten, die ich mit meinen Applikationen durch die Gegend schiebe, wären wahrscheinlich in einer DB besser aufgehoben. Das ist es ja, was so weh tut.

Umgekehrt drängt sich mir die Frage auf, warum man Xbase nutzen sollte, wenn man eben nicht mehr mit dbf/??x arbeitet, außer dass wir diese Sprache lieben wie unser Leben. Also fast zumindest. Und die Nutzung von dbf/??x sollte sicher möglich sein, unabhängig von SMB-Versionen. Eine Extra-Exe auf dem Server könnte das ermöglichen.

Da ich gerade ein anderes Client-Server-Projekt in Angriff nehme, juckt es mich schon sehr, die File-API-Call-Redirections mal rudimentär zu implementieren, zumal das nur wenige Zeilen Code wären.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von brandelh »

Laut der Doku von SQLite wird dringend vom sharen von Dateien abgeraten (auch der SQLite DB), da die Netzwerkschnittstellen nicht fehlerfrei sind und das bei jedem System.
Vermutlich, weil der gesharte Dateizugriff nicht mehr "üblich" oder "gewollt" ist. Optimiert wird in Richtung 2 User arbeiten auf einem Excel-sheet, oder gleich um Word Dateien schneller zu laden.

Wenn es aber so einfach wäre das mal schnell selbst zu machen, dann frage ich mich, warum das noch keiner getan hat ;-)

Vermutlich ist es sicher mit SQLexpress() über ODBC Treiber auf DBFs zuzugreifen (das per SQL Abfrage), aber ob das schnell genug ist (kein SQL Server der mit Indexen beschleunigen kann) ist eine andere Frage.
Ich habe oft mit sehr großen Dateien (400 MB) zu tun die ich einlese und sequentiell verarbeite, daher habe ich auch keinen Leidensdruck auf SQL Server zu gehen, solange die maximale Dateigröße der DBF nicht gerissen wird.
Für diesen Zweck, meist auch exclusiver Zugriff ist die DBF einfach ideal und auf der SSD rasend schnell.
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Tom »

Bei SQlite wird die Serversoftware quasi per Bibliothek in die Anwendungssoftware eingebunden, alle Daten sind monolithisch in einer einzigen Datei untergebracht, einschließlich der Trigger, Stored Procedures usw. Diese eine Datei kann und darf man nicht teilen, das widerspricht auch dem Ansatz von SQLite, das dafür gedacht ist, eine voll funktionsfähige SQL-Datenbank für den Einzel-Direktzugriff zur Verfügung zu stellen - vor allem auf Mobilgeräten, denn dafür ist es entwickelt worden. Entscheidend, wie gesagt: Die Anwendungssoftware trägt den Server quasi mit sich herum, und alles sonst steckt in einer einzigen Datei.
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von brandelh »

Das mit der einzigen Datei ist bei Access MDBs ja auch so ... ;-)

Was ich meinte ist dies:

https://www.sqlite.org/lockingv3.html
6.0 How To Corrupt Your Database Files hat geschrieben: On Windows it uses the LockFile(), LockFileEx(), and UnlockFile() system calls. SQLite assumes that these system calls all work as advertised. If that is not the case, then database corruption can result. One should note ... and that there are reports of locking problems for network filesystems under Windows. Your best defense is to not use SQLite for files on a network filesystem.

SQLite uses ... the FlushFileBuffers() to do the same under Windows. Once again, SQLite assumes that these operating system services function as advertised. But it has been reported that fsync() and FlushFileBuffers() do not always work correctly, especially with inexpensive IDE disks.
https://www.sqlite.org/threadsafe.html
Using SQLite In Multi-Threaded Applications hat geschrieben: 1. Overview
SQLite supports three different threading modes:

Single-thread. In this mode, all mutexes are disabled and SQLite is unsafe to use in more than a single thread at once.

Multi-thread. In this mode, SQLite can be safely used by multiple threads provided that no single database connection is used simultaneously in two or more threads.

Serialized. In serialized mode, SQLite can be safely used by multiple threads with no restriction.

The threading mode can be selected at compile-time (when the SQLite library is being compiled from source code) or at start-time (when the application that intends to use SQLite is initializing) or at run-time (when a new SQLite database connection is being created). Generally speaking, run-time overrides start-time and start-time overrides compile-time. Except, single-thread mode cannot be overridden once selected.

The default mode is serialized.
Wenn eine Anwendung mit mehreren Threads auf eine DB zugreifen kann, können auch mehrere Anwendungen auf dem gleichen Rechner auf die Datei zugreifen (serialized).
Selbstverständlich ist das nicht so leistungsfähig und sicher wie ein eigener SQL-Server mit eigenem Prozess, aber sicherlich nicht schlechter als die gesharten DBF Dateien.
Solange das OS macht, was es soll ! Auch wenn SQLite dafür sicher nicht gedacht war.

Meine Aussage oben bezog sich auf die Ausführungen zu den Fehlern in den Netzwerktreibern, weshalb SQLite empfiehlt die Dateien nur lokal abzulegen.
Das trifft uns genauso mit den DBF und auch von Access MDB hat man von Problemen gelesen.
Gruß
Hubert
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann »

Aua!
Wenn es aber so einfach wäre das mal schnell selbst zu machen, dann frage ich mich, warum das noch keiner getan hat
Wenn man sich immer diese Frage stellt, ...

Ich hab's probiert, ca. 300 Zeilen netto-code (client + server).

Läuft wunderbar. Geschwindigkeit brauchbar und man könnte noch Einiges rausholen.

Bild

Der Client greift ausschließlich über den Server auf das File zu. Eine simple Socket-Verbindung reicht. Kein login, kein share, kein net use, kein SMB.

Geht doch!

(Nicht vom Jahr beim Copyright stören lassen. Das kommt vom Kopieren der Vorlage. Alles frisch und noch heiß.)
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von AUGE_OHR »

und wo ist die maximal Grösse der Datenbank :?: 4 GB :roll:
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von brandelh »

mit Xbase++ konnte ich noch keine DBF von mehr als 2,4 GB erstellen, egal was ich beim Offset eingetragen habe.
Gruß
Hubert
Antworten