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
Ich denke mal wir sind uns in dem Punkt einig, das Xbase++ zwar ein ordentliches Werkzeug ist, mit dem man ordentliche Anwendungen schreiben kann. Und in manchen Punkten auch herrausragend ist. Aber insgesamt dem Markt arg hinterher hinkt. Wobei sich natürlich immer die Frage stellt: Brauch ich wirklich mehr, oder komm ich damit aus? Man muß ja auch nicht immer mit Kanonen auf Spatzen schießen, wenn die Flinte hervorragend ausreicht.
Das Argument, das auch die 2.0 bereits ein paar Jahre auf dem Buckel hat (halt sechs), zählt für mich nicht ganz so sehr. Denn wenn eine Firma auf CD umstellt, dann gibt es halt nicht mehr diese Versionssprünge im Monats- oder Jahresrhytmus. Selbst große Firmen machen das inzwischen so, siehe Windows 10. Das auch mehr Jahre als alle Versionen vorher auf der gleichen Versionsnummer stehen bleiben wird. Den Fortschritt sieht man nicht in der Versionsnummer sondern im Build.
Ich selber habe damit übrigens ein interessantes Problem: Meine Software war vor 2 oder 3 Jahren auf einer Pearl-CD. Die möchten mich für ende diesen jahres gerne wieder dabei haben. Geht aber nicht. Regel bei denen ist, niemals die gleiche Version noch einmal zu veröffentlichen. da ich aber schon seit 10 Jahren mit CD arbeite, die Versionsnumemr nur bei eklatanten Erweiterungen steigt, habe ich immer noch die gleiche Hauptnummer wie damals. Und nur wegen Pearl werde ich das nicht durchbrechen. Bin ich halt raus. Ich trauere da nicht allzu viel drum, den Schub hat das in den Verkaufszahlen dann auch nicht gebracht. Aber schon bezeichnend, das die Firmen oder verantwortlichen an Dingen festhalten, die höchstens Bauchgefühl, Unwissenheit, oder Werbestrategie sind. Aber real keinerlei Bedeutung haben.
Jan
Das Argument, das auch die 2.0 bereits ein paar Jahre auf dem Buckel hat (halt sechs), zählt für mich nicht ganz so sehr. Denn wenn eine Firma auf CD umstellt, dann gibt es halt nicht mehr diese Versionssprünge im Monats- oder Jahresrhytmus. Selbst große Firmen machen das inzwischen so, siehe Windows 10. Das auch mehr Jahre als alle Versionen vorher auf der gleichen Versionsnummer stehen bleiben wird. Den Fortschritt sieht man nicht in der Versionsnummer sondern im Build.
Ich selber habe damit übrigens ein interessantes Problem: Meine Software war vor 2 oder 3 Jahren auf einer Pearl-CD. Die möchten mich für ende diesen jahres gerne wieder dabei haben. Geht aber nicht. Regel bei denen ist, niemals die gleiche Version noch einmal zu veröffentlichen. da ich aber schon seit 10 Jahren mit CD arbeite, die Versionsnumemr nur bei eklatanten Erweiterungen steigt, habe ich immer noch die gleiche Hauptnummer wie damals. Und nur wegen Pearl werde ich das nicht durchbrechen. Bin ich halt raus. Ich trauere da nicht allzu viel drum, den Schub hat das in den Verkaufszahlen dann auch nicht gebracht. Aber schon bezeichnend, das die Firmen oder verantwortlichen an Dingen festhalten, die höchstens Bauchgefühl, Unwissenheit, oder Werbestrategie sind. Aber real keinerlei Bedeutung haben.
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.
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: SMB1 und Dateizugriff-Schweinkram
war klar das es auf so eine Diskussion raus läuft statt sich ans Thema zu halten ...
> Die normale Sharerei ist um den Faktor 100-400 schneller
@Mike : schon mal getestet wie "langsam" Windows wird wenn SMB abgeschaltet ist
> Die normale Sharerei ist um den Faktor 100-400 schneller
@Mike : schon mal getestet wie "langsam" Windows wird wenn SMB abgeschaltet ist
gruss by OHR
Jimmy
Jimmy
- Rudolf
- Programmier-Gott
- Beiträge: 1418
- Registriert: Mo, 02. Jan 2006 23:03
- Wohnort: Salzburg/Österreich
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
Hallo,
Tom: danke, genauso sehe ich es, vor allem mit dem technologischen Stand von xBase++. Jeder der sich für seinen Weg entschieden hat, hat seine Gründe. Und ich würde nie deshalb andere als weniger kompetent oder fahrlässig bezeichnen ohne die Gründe zu verstehen. Damit hoffentlich wirklich beendet
Jimmy: auch danke, wir sind wieder beim Thema Für mich ist das Maß für die Geschwindigkeit der Aufbau meiner komplexen Dialoge. Mir ist egal wie lange ein Index oder Pack dauert, das wird sowieso nur sehr selten verwendet, und dann kann ich die Zeit planen.
Grüße
Rudolf
Tom: danke, genauso sehe ich es, vor allem mit dem technologischen Stand von xBase++. Jeder der sich für seinen Weg entschieden hat, hat seine Gründe. Und ich würde nie deshalb andere als weniger kompetent oder fahrlässig bezeichnen ohne die Gründe zu verstehen. Damit hoffentlich wirklich beendet
Jimmy: auch danke, wir sind wieder beim Thema Für mich ist das Maß für die Geschwindigkeit der Aufbau meiner komplexen Dialoge. Mir ist egal wie lange ein Index oder Pack dauert, das wird sowieso nur sehr selten verwendet, und dann kann ich die Zeit planen.
Grüße
Rudolf
Rudolf Reinthaler
http://www.formcommander.net
http://www.formcommander.net
- 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
@Jimmy: Nee. Mir reicht, was ich gesehen habe.
Mit ein paar weiteren Experimenten SET EXCLUSIVE ON/OFF und skippen mit und ohne Datenzugriff sieht man sehr schön die Optimierungsmechanismen der DB-Engine und wie die manchmal sauber in die Binsen gehen. Aber die Bottomline ist schon, dass wir die hohe Geschwindigkeit unserer Applikationen dem Betriebssystem / SMBx zu verdanken haben. Wenn da was gedreht würde, wäre schnell Schluss mit lustig.
Ich habe auch den Eindruck gewonnen, dass die Anzahl der Anfragen an den Server das entscheidende Mass für die Geschwindigkeit ist. Die nachfolgenden Tests wurden wieder per Loopback gemacht.
1. Summe aller buyprices im shared mode der 1500 Sätze in der cars.dbf ohne Index: 2,97 Sekunden, 1541 Anfragen, 266KB Antwortdatenvolumen.
2. Summe aller buyprices im shared mode der 1500 Sätze in der cars.dbf mit Index: 13,6 Sekunden, 7550 Anfragen, 2,160MB Antwortdatenvolumen.
Der Testfall 1 zeigt auch sehr klar, wo die Grenzen für Phils DBFSERVER liegen. Denn schneller als das kann auch er nicht.
Sehr unschöne Ergebnisse.
Wenn ich das richtig interpretiere, würde ich folgende Schlüsse ziehen:
Solange ein Anwender sich satzweise durch die Daten hangelt und diese vielleicht auch ändert, ist die dbf-Philosophie weiterhin brauchbar. Sobald mehrere Sätze betroffen sind (sowohl lesend als auch schreibend), sollten die erforderlichen Operationen ausschließlich auf einem Server durchgeführt werden. So ein Code in unseren Programmen:
GO TOP
DO WHILE .NOT. EOF()
summe += FIELD->buyprice
SKIP 1
ENDDO
geht dann gar nicht mehr. Und da fällt das Kartenhaus der Hoffnung zusammen, alten Code einfach in die Zukunft portieren zu können. Diese Code-Strecke müsste an den Server zur Ausführung gesandt werden. Helm ab zum Gebet.
Man könnte das aber auch als Chance sehen.
Michael
Mit ein paar weiteren Experimenten SET EXCLUSIVE ON/OFF und skippen mit und ohne Datenzugriff sieht man sehr schön die Optimierungsmechanismen der DB-Engine und wie die manchmal sauber in die Binsen gehen. Aber die Bottomline ist schon, dass wir die hohe Geschwindigkeit unserer Applikationen dem Betriebssystem / SMBx zu verdanken haben. Wenn da was gedreht würde, wäre schnell Schluss mit lustig.
Ich habe auch den Eindruck gewonnen, dass die Anzahl der Anfragen an den Server das entscheidende Mass für die Geschwindigkeit ist. Die nachfolgenden Tests wurden wieder per Loopback gemacht.
1. Summe aller buyprices im shared mode der 1500 Sätze in der cars.dbf ohne Index: 2,97 Sekunden, 1541 Anfragen, 266KB Antwortdatenvolumen.
2. Summe aller buyprices im shared mode der 1500 Sätze in der cars.dbf mit Index: 13,6 Sekunden, 7550 Anfragen, 2,160MB Antwortdatenvolumen.
Der Testfall 1 zeigt auch sehr klar, wo die Grenzen für Phils DBFSERVER liegen. Denn schneller als das kann auch er nicht.
Sehr unschöne Ergebnisse.
Wenn ich das richtig interpretiere, würde ich folgende Schlüsse ziehen:
Solange ein Anwender sich satzweise durch die Daten hangelt und diese vielleicht auch ändert, ist die dbf-Philosophie weiterhin brauchbar. Sobald mehrere Sätze betroffen sind (sowohl lesend als auch schreibend), sollten die erforderlichen Operationen ausschließlich auf einem Server durchgeführt werden. So ein Code in unseren Programmen:
GO TOP
DO WHILE .NOT. EOF()
summe += FIELD->buyprice
SKIP 1
ENDDO
geht dann gar nicht mehr. Und da fällt das Kartenhaus der Hoffnung zusammen, alten Code einfach in die Zukunft portieren zu können. Diese Code-Strecke müsste an den Server zur Ausführung gesandt werden. Helm ab zum Gebet.
Man könnte das aber auch als Chance sehen.
Michael
-
- 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 Michael
das Kartenhaus braucht nicht zusammenzubrechen. Es gibt noch den ADS-Server.
Damit kannst du die DBF ohne auswirkungen von SMB und grosse Code-Anpassungen im Client-Server Betrieb bearbeiten.
Auch die von dir erwähnten Schlaufen sind möglich-
Nicht ganz so schnell wie die DBFNTX aber absolut zuverlässig und auch mit Verschlüsselung der Daten.
Oder wenn du Geschwindikeit pur möchtest dann Postgres nativ das stellt dann alles in den Schatten bedingt aber grosse Umbauten am Code.
Gruss Carlo
das Kartenhaus braucht nicht zusammenzubrechen. Es gibt noch den ADS-Server.
Damit kannst du die DBF ohne auswirkungen von SMB und grosse Code-Anpassungen im Client-Server Betrieb bearbeiten.
Auch die von dir erwähnten Schlaufen sind möglich-
Nicht ganz so schnell wie die DBFNTX aber absolut zuverlässig und auch mit Verschlüsselung der Daten.
Oder wenn du Geschwindikeit pur möchtest dann Postgres nativ das stellt dann alles in den Schatten bedingt aber grosse Umbauten am Code.
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- 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
Hallo Carlo,
ADS scheidet für mich aus. Das hat sehr rationale und sehr irrationale Gründe. Dennoch habe ich in Folge meiner Erkenntnisse ein wenig zum Thema ADS rumgegoogelt. Was ich gesehen habe, hat beide Grundkategorien in der Intensität gesteigert.
In meinem Kopf wächst im Moment ein ganz neues Pflänzchen, das diese Probleme beheben kann und noch ganz andere Chancen bietet. Stell Dir vor, Du schreibst Code, der zwar (pro Thread) sequentiell abläuft, das aber auf verschiedenen Rechnern tut. Und ich rede hier nicht von verschickten Codeblöcken oder Macros, sondern vom gleichen ausführbaren Code, der auf allen teilnehmenden Restaurants, nee Rechnern natürlich, vorliegt und ausgeführt wird.
Viele Grüße
Michael
ADS scheidet für mich aus. Das hat sehr rationale und sehr irrationale Gründe. Dennoch habe ich in Folge meiner Erkenntnisse ein wenig zum Thema ADS rumgegoogelt. Was ich gesehen habe, hat beide Grundkategorien in der Intensität gesteigert.
In meinem Kopf wächst im Moment ein ganz neues Pflänzchen, das diese Probleme beheben kann und noch ganz andere Chancen bietet. Stell Dir vor, Du schreibst Code, der zwar (pro Thread) sequentiell abläuft, das aber auf verschiedenen Rechnern tut. Und ich rede hier nicht von verschickten Codeblöcken oder Macros, sondern vom gleichen ausführbaren Code, der auf allen teilnehmenden Restaurants, nee Rechnern natürlich, vorliegt und ausgeführt wird.
Viele Grüße
Michael
-
- 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 Michael
Deine "Pflänzchenidee" ist nicht ohne. Bedeutet dann auch dezentrale Datenbestände was viele Probleme lösen würde. So lange diese nicht zu gross werden. Synchronisiert nach dem Blockchainsystem .... Muss auch mal darüber nachdenken.
Gruss Carlo
Verstehe voll und ganz. Wir verwenden den schon seit vielen vielen Jahren... Seit dem letzten Besitzerwechsel ist es noch ein "Notnagel" keine Neuinstallationen mehr. Mein Ziel ist weg von ADS der komplette Umbau der Programme auf Postgres mit Browser basierender Oberfläche.Was ich gesehen habe, hat beide Grundkategorien in der Intensität gesteigert.
Deine "Pflänzchenidee" ist nicht ohne. Bedeutet dann auch dezentrale Datenbestände was viele Probleme lösen würde. So lange diese nicht zu gross werden. Synchronisiert nach dem Blockchainsystem .... Muss auch mal darüber nachdenken.
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- 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
Hallo Carlo,
über so wildes Zeug wie Block-Chain Sachen denke ich nicht nach. Mir geht's nur drum, den Code da laufen zu lassen, wo es am günstigsten ist. Mit der genannten Lauf-Verteilung kriegt man das konkrete Problem und eventuell noch ein paar mehr in den Griff. Außerdem hängt man nicht von Anfang an am Detail der DBF-Problematik. Die kriegt man am Ende non-chalant hin. Hoffentlich zumindest.
Zu stellende Frage: Kann man feststellen, wo eine Code-Strecke am besten läuft? Sagen wir mal ja, in Extremfällen kann der Programmierer ja noch mitwirken. Aber diese DO WHILE .NOT. EOF() Dinger oder andere Schleifen mit SKIPs oder GOTOs oder SEEKs sollte man schon mit einem Preprozessor erkennen können. Mit dem verschiebt man den Schleifenkörper in eine eigene Funktion (im gleichen Modul) und ändert den Code so, dass alle im Schleifenkörper verwendeten Variablen Parameter der Funktion werden. In den Original-Code wird dann einfach der Aufruf dieser Funktion reingesetzt. Fertig. Damit würde das Progrämmchen erst mal tickern wie vorher.
Wenn nun derselbe Code (also auch die Substitions-Funktion) auf einem entfernten Rechner zur Verfügung stünde, müsste man nur die Parameter rüberschaukeln und den Code da ausführen. Wenn das der Server wäre, könnten plötzlich alle Client-Killer-Programmteile auf dem Server laufen.
Jetzt höre ich schon wieder alle rumschreien, so einfach wäre das nicht. Dann bitte ich doch mal um Nennung von konkreten Problemen. Einige fallen mir auch gleich ein, aber mit etwas Einschränkung keine, die nicht lösbar wären.
Viele Grüße
Michael
über so wildes Zeug wie Block-Chain Sachen denke ich nicht nach. Mir geht's nur drum, den Code da laufen zu lassen, wo es am günstigsten ist. Mit der genannten Lauf-Verteilung kriegt man das konkrete Problem und eventuell noch ein paar mehr in den Griff. Außerdem hängt man nicht von Anfang an am Detail der DBF-Problematik. Die kriegt man am Ende non-chalant hin. Hoffentlich zumindest.
Zu stellende Frage: Kann man feststellen, wo eine Code-Strecke am besten läuft? Sagen wir mal ja, in Extremfällen kann der Programmierer ja noch mitwirken. Aber diese DO WHILE .NOT. EOF() Dinger oder andere Schleifen mit SKIPs oder GOTOs oder SEEKs sollte man schon mit einem Preprozessor erkennen können. Mit dem verschiebt man den Schleifenkörper in eine eigene Funktion (im gleichen Modul) und ändert den Code so, dass alle im Schleifenkörper verwendeten Variablen Parameter der Funktion werden. In den Original-Code wird dann einfach der Aufruf dieser Funktion reingesetzt. Fertig. Damit würde das Progrämmchen erst mal tickern wie vorher.
Wenn nun derselbe Code (also auch die Substitions-Funktion) auf einem entfernten Rechner zur Verfügung stünde, müsste man nur die Parameter rüberschaukeln und den Code da ausführen. Wenn das der Server wäre, könnten plötzlich alle Client-Killer-Programmteile auf dem Server laufen.
Jetzt höre ich schon wieder alle rumschreien, so einfach wäre das nicht. Dann bitte ich doch mal um Nennung von konkreten Problemen. Einige fallen mir auch gleich ein, aber mit etwas Einschränkung keine, die nicht lösbar wären.
Viele Grüße
Michael
-
- 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 Michael
mit einer Web-App hättest du ja genau das.
Die ganzen goto's skip's usw, laufen alle auf einem Server.
Du sendest vom Browser über https Anforderungen an den Server, auf diesem läuft den Code, erstellt die Antwort und sendet diese Zurück.
Die Möglichkeiten um Masken im Browser darzustellen sind beinahe unbegrenzt. es gibt viele viele Add ons in JS die du verwenden kannst.
Xb2Net als Web-Server in Xbase ist ein guter Einstieg für Web-Apps. Du brauchst kein Apache oder IIS deine EXE ist alleine der Webserver.
Anstelle von Code-Teilen zum erreichen besserer Leistung zur Ausführung auf einen anderen Rechner zu senden sehe ich den Weg eindeutig beim Umstieg auf Postgres. Die DBF basierenden Datenbanken können mit der Performance von Postgres in keiner Weise mithalten.
Die grösste Postgres Datenbank mit der ich arbeite hat momentan 535'000'000 Datensätze hier einige Sätzte zu suchen was bei DBF's z.B. einem set filter to entspricht dauert ca. 0,1 Sek. Das Ergeniss sind einige 100 Datensätze ich finde dies zeigt eindrücklich dass es für DBF's Grenzen gibt wenn man diese erreicht ist der bessere Weg vermutlich schon die Datenbank zu wechseln. Leider bleibt uns der einfachste Weg dies zu tun, einfach die DBE zu tauschen wie uns Alaska lange versprach, verschlossen. Die Alaska PGDBE versagt hier komplett.
Gruss Carlo
mit einer Web-App hättest du ja genau das.
Die ganzen goto's skip's usw, laufen alle auf einem Server.
Du sendest vom Browser über https Anforderungen an den Server, auf diesem läuft den Code, erstellt die Antwort und sendet diese Zurück.
Die Möglichkeiten um Masken im Browser darzustellen sind beinahe unbegrenzt. es gibt viele viele Add ons in JS die du verwenden kannst.
Xb2Net als Web-Server in Xbase ist ein guter Einstieg für Web-Apps. Du brauchst kein Apache oder IIS deine EXE ist alleine der Webserver.
Anstelle von Code-Teilen zum erreichen besserer Leistung zur Ausführung auf einen anderen Rechner zu senden sehe ich den Weg eindeutig beim Umstieg auf Postgres. Die DBF basierenden Datenbanken können mit der Performance von Postgres in keiner Weise mithalten.
Die grösste Postgres Datenbank mit der ich arbeite hat momentan 535'000'000 Datensätze hier einige Sätzte zu suchen was bei DBF's z.B. einem set filter to entspricht dauert ca. 0,1 Sek. Das Ergeniss sind einige 100 Datensätze ich finde dies zeigt eindrücklich dass es für DBF's Grenzen gibt wenn man diese erreicht ist der bessere Weg vermutlich schon die Datenbank zu wechseln. Leider bleibt uns der einfachste Weg dies zu tun, einfach die DBE zu tauschen wie uns Alaska lange versprach, verschlossen. Die Alaska PGDBE versagt hier komplett.
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Rudolf
- Programmier-Gott
- Beiträge: 1418
- Registriert: Mo, 02. Jan 2006 23:03
- Wohnort: Salzburg/Österreich
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
Hallo Carlo,
also mich nervt es in der Zwischenzeit sehr dass Du ständig jeden mit Deinem Weg missionieren willst. Es gibt auch andere Wege und Meinungen, hier gehts um die Lösung von Michael, jede andere Diskussion sollte in einem anderen Thread laufen denke ich. Es wird sonst wirklich mühsam. Sorry, das musst ich mal loswerden.
Grüße
Rudolf
also mich nervt es in der Zwischenzeit sehr dass Du ständig jeden mit Deinem Weg missionieren willst. Es gibt auch andere Wege und Meinungen, hier gehts um die Lösung von Michael, jede andere Diskussion sollte in einem anderen Thread laufen denke ich. Es wird sonst wirklich mühsam. Sorry, das musst ich mal loswerden.
Grüße
Rudolf
Rudolf Reinthaler
http://www.formcommander.net
http://www.formcommander.net
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: SMB1 und Dateizugriff-Schweinkram
hi Carlo,
die 2GB DBF Grenze ist natürlich DER Grund auf SQL zu wechseln.
---
Das Problem der Entwickler ist der vorhandene Source Code der Userdas wäre eine normale xBase Schleife die hier aus 6 Zeile besteht.
mit der ISAM Emulation von PgDBE läuft so ein "normaler" Code mit WHILE !EOF() und SKIP extrem langsam.
nun wird es auch mit der native Version nicht viel schneller wenn man solchen Source Code übernimmt ...
man muss schon anderen Code schreiben/optimieren.
wenn ich nun solchen Source Code vorliegen hätte
könnte man daraus dann das in SQL machen
ein Pre-Prozessor müsste also die "Bedingung erkennen" und die ganze DO WHILE Schleife "auflösen".
ob man solchen Code per Pre-Prozessor erzeugen kann
... besser wäre es wohl wie bei Express++ mit eigener Syntax.
p.s. der Demo-Code ist nicht auf Syntax geprüft sondern dient nur der Verdeutlichung der Idee
die 2GB DBF Grenze ist natürlich DER Grund auf SQL zu wechseln.
---
Das Problem der Entwickler ist der vorhandene Source Code der User
Code: Alles auswählen
DO WHILE !EOF()
IF Bedingung()
AAdd( aArray, RecNo() )
ENDIF
SKIP
ENDDO
mit der ISAM Emulation von PgDBE läuft so ein "normaler" Code mit WHILE !EOF() und SKIP extrem langsam.
nun wird es auch mit der native Version nicht viel schneller wenn man solchen Source Code übernimmt ...
man muss schon anderen Code schreiben/optimieren.
wenn ich nun solchen Source Code vorliegen hätte
Code: Alles auswählen
DbEval( {|| AAdd( aArray, RecNo() ) } , Bedingung() )
Code: Alles auswählen
SELECT * FROM ABC WHERE Bedingung()
ob man solchen Code per Pre-Prozessor erzeugen kann
... besser wäre es wohl wie bei Express++ mit eigener Syntax.
p.s. der Demo-Code ist nicht auf Syntax geprüft sondern dient nur der Verdeutlichung der Idee
gruss by OHR
Jimmy
Jimmy
-
- 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 Rudolf
"Missionieren" geht anders. Ich habe einen Teil unserer Erlebnisse und Erfahrungen mit euch geteilt. Dank diesen Erkenntnissen und den daraus gezogenen Veränderungen konnten wir überleben. Auch andere User hier haben mit Sicherheit auch schon Kunden an andere Anbeiter mit Web-Apps verloren. Wenn dich das derart nervt gut. Kann ich aktzeptieren und schweigen.
** Dies war mein letzter Beitrag zu diesem Thema **
Gruss Carlo
"Missionieren" geht anders. Ich habe einen Teil unserer Erlebnisse und Erfahrungen mit euch geteilt. Dank diesen Erkenntnissen und den daraus gezogenen Veränderungen konnten wir überleben. Auch andere User hier haben mit Sicherheit auch schon Kunden an andere Anbeiter mit Web-Apps verloren. Wenn dich das derart nervt gut. Kann ich aktzeptieren und schweigen.
** Dies war mein letzter Beitrag zu diesem Thema **
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Rudolf
- Programmier-Gott
- Beiträge: 1418
- Registriert: Mo, 02. Jan 2006 23:03
- Wohnort: Salzburg/Österreich
- Kontaktdaten:
Re: SMB1 und Dateizugriff-Schweinkram
Hallo Carlo,
das Thema ist ja berechtigt, aber bei jedem andren Thema damit wieder zu beginnen ist für mich das Problem. Wieso machst Du nicht einen eignen Thread in dem es nur um dieses Thema geht ?
Grüße
Rudolf
das Thema ist ja berechtigt, aber bei jedem andren Thema damit wieder zu beginnen ist für mich das Problem. Wieso machst Du nicht einen eignen Thread in dem es nur um dieses Thema geht ?
Grüße
Rudolf
Rudolf Reinthaler
http://www.formcommander.net
http://www.formcommander.net
- 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
@Carlo:
selbstverständlich kann man auf eine SQL-Server-basierte Lösung umstellen. Danach hast Du aber ein anderes Programm und eine andere Philosophie. Mir stellt sich da zwangsläufig die Frage, ob ich nicht gleich meine Insel verlasse und ans Festland wechsle, wenn ich sowieso schon so lange schwimmen muss. Andere Inseln des Galapagos Archipels scheiden natürlich aus.
Das schließt natürlich nicht aus, dass ich z.B. den Postgres-Server verwende, wenn ich ihn brauche. Ich würde aber nie daran denken, ihn als Ersatz für dbf-Tabellen zu nehmen. Wir haben das intern untersucht und nach Sachlage irgenwann beschlossen, das Thema nicht weiter zu verfolgen. Diesmal nur aus rationalen Gründen.
Da ich kein Problem damit habe, einen Server zu schreiben, ziehe ich den Weg der Eigenentwicklung vor. Ob ich den Kommunikations-Stream pur von Socket zu Socket schicke oder ob ich mich auf ein Protokoll aufschalte (https, ...) ist mir dann schnuppe. Außer es geht um Geschwindigkeit, dann gilt "lean is mean" und das muss ich beherrschen.
@Jimmy:
Es gibt, denke ich, eine endliche Anzahl Schlüsselworte, anhand derer man eine Codestrecke automatisch erkennen sollte, die besser auf einem anderen Rechner läuft. Dass das mit dem Xbase++ Preprozesser nicht gehen wird, liegt schon daran, weil der nur einzelne Statements bearbeiten kann. Außerdem denkst Du schon gleich wieder im konkreten Problem. Das versuche ich noch zu vermeiden.
Was das DBF-2GB-Problem angeht, so ließe sich dies mit meinem Ansatz lösen. Der Workarea-Status wäre nämlich etwas, was zwischen den Rechnern ausgetauscht werden müsste.
@Alle:
Meine Perspektive ist: Ich habe ein Programm, das verteilt auf mehreren Rechnern laufen kann. Wo es läuft, hängt am Ende davon ob, welche Rechner zur Verfügung stehen. Die Verteilung kann großteils automatisch erfolgen, aber der Programmierer kann das natürlich auch bestimmen.
Jetzt geht es darum, rauszufinden, an welchen Gegebenheiten dieses Konzept scheitern könnte, welche Grenzen ihm gesetzt sind, wo man damit noch tierisch punkten könnte oder ob es angesichts der aktuellen Bedrohungslage eine kompletter Schmarrn ist, über sowas überhaupt nachzudenken.
Schönen Sonntag
Michael
selbstverständlich kann man auf eine SQL-Server-basierte Lösung umstellen. Danach hast Du aber ein anderes Programm und eine andere Philosophie. Mir stellt sich da zwangsläufig die Frage, ob ich nicht gleich meine Insel verlasse und ans Festland wechsle, wenn ich sowieso schon so lange schwimmen muss. Andere Inseln des Galapagos Archipels scheiden natürlich aus.
Das schließt natürlich nicht aus, dass ich z.B. den Postgres-Server verwende, wenn ich ihn brauche. Ich würde aber nie daran denken, ihn als Ersatz für dbf-Tabellen zu nehmen. Wir haben das intern untersucht und nach Sachlage irgenwann beschlossen, das Thema nicht weiter zu verfolgen. Diesmal nur aus rationalen Gründen.
Da ich kein Problem damit habe, einen Server zu schreiben, ziehe ich den Weg der Eigenentwicklung vor. Ob ich den Kommunikations-Stream pur von Socket zu Socket schicke oder ob ich mich auf ein Protokoll aufschalte (https, ...) ist mir dann schnuppe. Außer es geht um Geschwindigkeit, dann gilt "lean is mean" und das muss ich beherrschen.
@Jimmy:
Es gibt, denke ich, eine endliche Anzahl Schlüsselworte, anhand derer man eine Codestrecke automatisch erkennen sollte, die besser auf einem anderen Rechner läuft. Dass das mit dem Xbase++ Preprozesser nicht gehen wird, liegt schon daran, weil der nur einzelne Statements bearbeiten kann. Außerdem denkst Du schon gleich wieder im konkreten Problem. Das versuche ich noch zu vermeiden.
Was das DBF-2GB-Problem angeht, so ließe sich dies mit meinem Ansatz lösen. Der Workarea-Status wäre nämlich etwas, was zwischen den Rechnern ausgetauscht werden müsste.
@Alle:
Meine Perspektive ist: Ich habe ein Programm, das verteilt auf mehreren Rechnern laufen kann. Wo es läuft, hängt am Ende davon ob, welche Rechner zur Verfügung stehen. Die Verteilung kann großteils automatisch erfolgen, aber der Programmierer kann das natürlich auch bestimmen.
Jetzt geht es darum, rauszufinden, an welchen Gegebenheiten dieses Konzept scheitern könnte, welche Grenzen ihm gesetzt sind, wo man damit noch tierisch punkten könnte oder ob es angesichts der aktuellen Bedrohungslage eine kompletter Schmarrn ist, über sowas überhaupt nachzudenken.
Schönen Sonntag
Michael