Der Weg zu SQL?

alles was zunächst nicht kategorisierbar ist

Moderator: Moderatoren

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:

Der Weg zu SQL?

Beitrag von satmax »

Hallo,

ich bin in den letzten Wochen mit meiner Umstellung CL5.2 auf Xbase++ (full GUI) sehr weit gekommen, habe jetzt aber ein echtes Performance Problem. Lokal gerade noch annehmbare Antwortzeiten von 1-2 Sekunden (SSD HD) werden im GB Netzwerk zu 2-4 Sekunden, auf meinem Notebook mit W-Lan 10-15 Sekunden um einen Auftrag anzuzeigen. Da rede ich noch gar nicht von Mehrfachzugriff! Unter CLipper 5.2 waren die Antwortzeiten immer unter 1 Sekunde! Nur so am Rande: warum ist hier Xbase++ eigentlich so langsam?

Da ich hier auch immer wieder von anderen Problemen mit DBF/CDX Dateien lese, überlege ich einen SQL Server zu verwenden.

Welche Möglichkeiten gibt es auf einen SQL Server zu wechseln? Ich habe etwas Erfahrung mit dem MS-SQL Server da ich einige Programme auf dieser Basis betreue. Außerdem sollte ich teilweise auf ein paar Stammdaten vom MS SQL Server zugreifen. Daher wäre mir der MS-SQL Server am liebsten, ist aber nur ein Wunsch, kein KO Kriterium. Programmiert mit SQL habe ich noch nie, einfache SQL Queries habe ich schon durchgeführt. Das Prinzip mit dem Cursor und der Datenmenge ist mir klar. Auch das es praktisch keinen Recordlock gibt.

Welche Möglichkeiten stehen in einem vernünftigen Aufwand gegenüber um auf ein gut funktionierendes und stabiles SQL-System zu portieren? Zur Zeit verwende ich Xbase++ und TopDown. TopDown unterstützt teilweise SQL in Verbindung mit SQL Express. Die ganz groben Kosten für die erforderliche Anschaffungen wären auch interessant (Runtime/einmalig).

Was bietet sich hier an?

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

Re: Der Weg zu SQL?

Beitrag von brandelh »

Ich kenne mich mit dem MsSQL Server nicht aus, insbesondere nicht mit der Lizenz-Frage (Preis, User-Anzahl).
Es gab da ja eine Version die kostenlos ist (Express oder so ... ), ob DU die aber mit ausliefern darfst ?

Bei MySQL ist klar, dass der KUNDE diesen installieren und auch mit deinem Programm kostenlos nutzen darf,
aber DU als Softwarehersteller, darfst diesen nach meinem Kenntnisstand nicht einfach mitliefern (du dürftest den sicher dort im Auftrage installieren) ...

Nur PostGreSQL kennt keinerlei Restriktionen was das Lizenz-Recht betrifft.
Angeblich kann PostGreSQL mehr, wenn man die speziellen LIBs nutzt ... georg kann dir da mehr zu sagen.
Dies ist auch der Grund warum Alaska diesen (in älterer Version) für Xbase++ 2.0 einsetzen will.

Wenn DU vorschreiben kannst welcher Server genutzt wird, dann kannst du dir heraussuchen was am sinnvollsten ist.

Wenn NICHT, dann ist SQLexpress() immer die beste Lösung, dein Programm nutzt immer die gleiche Schnittstelle und solange du bei Standard SQL bleibst,
musst du nur den connect string anpassen. Ich persönlich habe mit MySQL gute Erfahrungen gemacht.

Ein Endanwender könnte überfordert sein wenn er den Server installieren soll, auch die Datensicherung kann man nicht einfach mit dem Kopieren der Dateien erledigen,
aber grundsätzlich muss man nur einen USER auf dem SQL-Server anlegen, der genug Rechte hat um die Tabellen anzulegen.
Ich habe z.B. eine datenbank in MySQL angelegt, die die Daten für ein Projekt verwalten soll.
Für diese Datenbank (und nur für diese) habe ich einen XYZ-Admin und XYZ-User angelegt.
Der Admin wird vom Programm benutzt um die Tabellen anzulegen (SYNTAX aus einer Datensicherung abgeschrieben), der andere für normale Arbeiten.

Die normale Anwendung selbst läuft auf meinem kleinen Testserver als WEB CGI Anwendung (in PowerBasic mit SQLTOOL - ähnlich SQLexpress).
Für die Verwaltung habe ich ein kleines Ladeprogramm geschrieben, das die Inhalte (Bilder, Infos etc.) automatisiert hochlädt - und auch fehlende Tabellen einrichtet. NUR dieses nutzt den XYZ-Admin user. Der SQL Server (Root) Admin wird nicht verwendet. Kennwörter etc. liegen in der EXE (die auf meinem lokalen Server vor Zugriffen geschützt ist).

Wegen der CGI Anwendung kann ich aber nicht beurteilen, wie sich das bei vielen GUI Anwendern verhalten würde, wenn nur ein USER für eine EXE und viele Anwender agiert.
Ich wollte /konnte keinesfalls für jeden Anwender einen USER Account auf dem Server erstellen, da muss georg oder uli was dazu sagen.

Eigentlich müsste eine SQL Datenbank administriert - auf jeden Fall gesichert werden.
ABER - wie war das mit den DBF ?
Genau, deine Anwendung hat das gemacht und ich wage zu behaupten, dass in einer 10 User Anwendung, das auch in Zukunft genau so geht.
DU kopierst per Anwendung die Daten, wenn keiner den SQL-Server bedienen kann.
DU legst im Programm die Felder fest die du brauchst und notfalls fügst dein Programm in einer neuen Version die neuen Felder dazu, das habe zumindest bei Android mit SQLite getan und sollte auch bei SQL-Servern funktionieren (Syntax habe ich grad nicht da ...)

Mit SQLexpress habe ich vor einigen Jahren Daten aus einer Access-Anwendung herausgeholt ohne Access nutzen zu müssen.
Ebenso habe ich riesige Datenmengen in eine MySQL / PostGreSQL geschaufelt um zu sehen ob das besser ist als die bisherige DBF Version (800 MB ist die DBF aktuell).
Da hatte ich allerdings Performance Probleme über ODBC ... das mache ich heute immer noch mit DBF weil diese für eine lineare Verarbeitung einfach einfacher ist ;-)

Große Datenbestände zu laden geht aber immer noch am schnellsten, wenn man mit Xbase++ eine Textdatei mit den SQL Ladebefehlen (ähnlich einer SQL Datensicherung) anlegt und diese Datei direkt am Server über die Admin Konsole startet ...
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: Der Weg zu SQL?

Beitrag von Jan »

... man könnte natürlich auch auf Xbase++ 2.0 warten ...

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
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: Der Weg zu SQL?

Beitrag von satmax »

brandelh hat geschrieben:Ich kenne mich mit dem MsSQL Server nicht aus, insbesondere nicht mit der Preisgestalltung.
Es gab da ja eine Version die kostenlos ist (Express oder so ... ), ob DU die aber mit ausliefern darfst ?
MS SQL ist gratis und man darf die Runtime mitliefern und installieren. Viele meiner Kunden haben den bereits, einige auch die Vollversion. Die mit der Vollversion haben eigene EDV-Abteilungen. Einen Sicherungsjob anzulegen ist mit der MMC auch kein Problem. Da erstelle ich jede Nacht eine Sicherung auf die HD, für die weitere Sicherung ist der Kunde verantwortlich. Einschränkungen gibt es mit der Anzahl der User und der DB Größe, nur ein Prozessor und 1 oder 2 GB Hauptspeicher. Wobei die DB Größe aktuell schon bei 10 GB liegt. IMHO geht das für 5-10 User problemlos.


Kleiner Nachtrag: wenn 2 Arbeitsplätze gleichzeitig zugreifen braucht jeder Rechner ca. 35 Sekunden um einen Auftrag anzuzeigen, unter CL 5.2 immer weit unter 1 Sekunde!
Das ganze mit Top Hardware.


Gruß
Markus
Gruß
Markus
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: Der Weg zu SQL?

Beitrag von satmax »

Jan hat geschrieben:... man könnte natürlich auch auf Xbase++ 2.0 warten ...

Jan
Vom Regen in die Traufe... Null Erfahrung, Erscheinungsdatum darf getippt werden: 2014, 2017 oder 2019... :(

Gibt es jemanden der schon eine Anwendung auf V2 portiert hat, mit SQL?

Ernsthaft, ich suche für jetzt eine praktikable Lösung. Wobei mir schleierhaft ist, wie mit diesen Antwortzeiten überhaupt jemand ein Xbase++ Programm vertreiben kann, eventuell habe ich ja auch ein hausgemachtes Problem!?


Gruß
Markus
Gruß
Markus
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Der Weg zu SQL?

Beitrag von Manfred »

Hallo Markus,

wenn Du so lange Antwortzeiten hast, dann würde ich generell einmal prüfen, wie Du programmierst. Ich merke auch teilweise deftige Unterschiede, aber so extrem ist es mir nicht ausgefallen bisher. da stimmt irgendwas anderes nicht. (Meine Meinung) Ich benutze zwar Linux mit Samba, aber wenn es so wäre wie Du beschreibst, dann dürften sich meine Kunden schon beschwert haben. Aber bisher habe ich sowas noch nicht gehört. Und schon gar nicht bei 2-3 Usern im Netz.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
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: Der Weg zu SQL?

Beitrag von satmax »

Manfred hat geschrieben:Hallo Markus,

wenn Du so lange Antwortzeiten hast, dann würde ich generell einmal prüfen, wie Du programmierst. Ich merke auch teilweise deftige Unterschiede, aber so extrem ist es mir nicht ausgefallen bisher. da stimmt irgendwas anderes nicht. (Meine Meinung) Ich benutze zwar Linux mit Samba, aber wenn es so wäre wie Du beschreibst, dann dürften sich meine Kunden schon beschwert haben. Aber bisher habe ich sowas noch nicht gehört. Und schon gar nicht bei 2-3 Usern im Netz.
Im Prinzip sind es simple Programmteile, eine Auftragsdb mit ca. 200000 Aufträgen und an die 8 via eindeutigem Key erstellte Relationen plus 2 Scopes. Lokal sind die Antwortzeiten akzeptabel, darum ist es mir auch bisher nicht aufgefallen, ein PC im Netz geht noch, so lange es ein GB Netz ist und kein WLAN. Bei 2 im Netz bricht alles zusammen, und das bei nur lesendem Zugriff! Zu diesem Zeitpunk wir kein einziger dbRLock() ausgeführt, eigentlich nur ein dbSkip().


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

Re: Der Weg zu SQL?

Beitrag von brandelh »

satmax hat geschrieben:
brandelh hat geschrieben:Ich kenne mich mit dem MsSQL Server nicht aus, insbesondere nicht mit der Preisgestalltung.
Es gab da ja eine Version die kostenlos ist (Express oder so ... ), ob DU die aber mit ausliefern darfst ?
MS SQL ist gratis und man darf die Runtime mitliefern und installieren. Viele meiner Kunden haben den bereits,
Ich hatte mal gelesen, dass man die damalige Version nur mitliefern darf, wenn man Microsoft Compiler nutzt, kann mich aber auch irren oder das hat sich geändert. ;-)
satmax hat geschrieben:Einen Sicherungsjob anzulegen ist mit der MMC auch kein Problem. Da erstelle ich jede Nacht eine Sicherung auf die HD, für die weitere Sicherung ist der Kunde verantwortlich.
du könntest ja mal dazu eine Anleitung veröffentlichen ... :wink:
satmax hat geschrieben:Kleiner Nachtrag: wenn 2 Arbeitsplätze gleichzeitig zugreifen braucht jeder Rechner ca. 35 Sekunden um einen Auftrag anzuzeigen,
unter CL 5.2 immer weit unter 1 Sekunde! Das ganze mit Top Hardware.
Meine Terminalserver Anwendung hier wird von etwa 10 Stationen gleichzeitig genutzt.
Die Daten sind auf 4 Dateien verteilt:
STAMM (4.000 Datensätze, 1 MB)
JAHR (16.000 Datensätze, 2,7 MB)
REAL-EK (88.000 Datensätze, 12 MB)
FIKTIV-EK(33.000 Datensätze, 5 MB)
Zugriff über das Aktenzeichen mit Index, zuerst Stamm, dann Jahr(1:3), dann Real / Fiktiv, alle Dateien bleiben offen ... Compiliert mit GUI Schalter wegen Drucken, aber @ SAY Oberfläche.
Keine Browser ! Anzeige der Eingabeseiten sofort (<1 sec), speichern 1 bis 2 Sek.
Nach Fehlern dauerte das neu Indizieren auf dem alten Win2000 Server (nur Daten) etwa 5 Minuten (über 32 MBit WAN-Leitung), nun wurden die DBFs auf Speichersubsysteme verlagert, die bei den TS-Servern im RZ stehen. Nun werden die Indexe in 15 Sekunden aufgebaut und auch ein TBrowse über alle Daten ist schnell (<2 Sek), vorher dauerte das gefühlt ewig.
Die reinen Daten pro Fall sind aber etwa 1 Stammdatensatz, 1 aus 2 Jahressätzen, 2 bis etwa 5 bis 10 (selten über 20) Real-EK, 2 bis 3 Fiktiv-EK Zeilen.
Das ging auch vorher schnell.

Das mittlerweile abgelöste richtige GUI Programm hat sich seine Daten aus 5 Dateien suchen müssen und verhielt sich wie WORD/EXCEL ... alle Daten in Array einlesen und anbieten ...
Ladezeit im LAN < 2 Sek., Speichern 3 bis 4 Sek. je nach Auslastung des Systems (alle Daten in den 5 Dateien verteilen).

Ich sage mal so, 1 Rechnung mit 100 Datensätzen muss unter 2 Sekunden geladen sein (im Speicher), wenn allerdings viele Felder vorliegen und ein Browser ins Spiel kommt, da kann es dauern.
XbpBrowse() ist langsam, ich nutze normalerweise nur XbpQuickBrowse() mit Anzeige und gepufferte Daten ( DacPagedDataStore() ) zur Anzeige. Wenn dann eine Zeile geändert werden soll zeige ich ein eigenes Edit-Fenster mit SLE/MLE. Man kann auch ein SLE so einblenden, dass es aussieht als gäbe man direkt in der Zelle ein, aber eine eigene Seite mit Validierung und Speichern/Abbrechen hat was !
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Der Weg zu SQL?

Beitrag von brandelh »

WLAN - ist SEHR anfällig für Störungen, wenn irgend möglich, CAT6 Kabel und einen guten switch verwenden !
Auch beim Lesen muss der Index gesperrt werden, wenn dann über eine gestörte WLAN Leitung immer wieder versucht wird gegenseitig die Dateien zu sperren kann das zäh werden.
Häufig sind es aber eben auch kleine Sünden (Syntax korrekt, aber nicht optimiert), die lokal keine Rolle spielen im zuverlässigen Netz noch so durchgehen aber in sensiblen Netzen tötlich enden.

Relationen z.B. können je nach Komplexität sehr schnell zu endlosem Springen führen.
Ich nutze immer dbSeek() für den ersten Satz, wenn man dann die Daten aus den anderen braucht, dort dbSeek() oder Scope() je nach Bedarf.
So wird nur bewegt was man wirklich braucht, Festplatten sind nunmal träge ... und wenn sich die Latenzen häufen ...

Dir könnte das verbesserte Sperren etwas bringen, aber ob das mit Clipper Comix geht weiß ich nicht:
Doku hat geschrieben:DBE_LOCKMODE

Mit der Konstante DBE_LOCKMODE kann das Verfahren für implizite Dateisperren vorgegeben werden. Wann immer auf die Index-Datei zugegriffen wird, erfolgt eine implizite Dateisperre um die Integrität der Operation zu gewährleisten. Voreingestellt für DBE_LOCKMODE ist LOCKING_STANDARD - ein Clipper und FoxPro kompatibles Verfahren. Das Standardverfahren ist jedoch im Kontext moderner Hardware nicht sehr effizient. Wird LOCKING_EXTENDED
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: Der Weg zu SQL?

Beitrag von satmax »

Hallo Hubert,

WLAN lasse ich im Moment außen vor. Laut Handbuch liest SET RELATION den Record erst wenn Daten aus diesem Rec benötigt werden. Und warum geht es mit einem PC, bei 2 bricht aber bereits alles zusammen, dazu reicht es wenn das Programm am 2 PC gestartet wird. Starte ich das Programm auf eine PC mehrmals, ist alles ok und ich bemerke keinen Unterschied!

Ich habe die Möglichkeit ganze Auftrage zu kopieren (inkl. aller Subtabellen). Lokal kann ich in einem Task 100 Aufträge kopieren (das sind ca. 500-700 Datensätze mit den Verknüpfungen), das dauert dann ca. 30-40 Sekunden. In dieser Zeit kann ich auf dem zweiten Task praktisch ohne Verzögerung durch die Aufträge blättern! Das ist alles völlig ok. Aber was passiert da im Netz?

Habe das Programm auch schon per UNC gestartet, mit DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE , LOCKING_EXTENDED ), immer das gleiche.

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

Re: Der Weg zu SQL?

Beitrag von brandelh »

satmax hat geschrieben:Laut Handbuch liest SET RELATION den Record erst wenn Daten aus diesem Rec benötigt werden.
Es geht um das Positionieren, was tatsächlich abgeht, keine Ahnung ;-)
satmax hat geschrieben:Und warum geht es mit einem PC, bei 2 bricht aber bereits alles zusammen, dazu reicht es wenn das Programm am 2 PC gestartet wird.
Starte ich das Programm auf eine PC mehrmals, ist alles ok und ich bemerke keinen Unterschied!
Habe das Programm auch schon per UNC gestartet, mit DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE , LOCKING_EXTENDED ), immer das gleiche.
das hört sich nach Jimmys Liblingsthema an.
Gruß
Hubert
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: Der Weg zu SQL?

Beitrag von georg »

Hallo,


grundsätzlich stellt sich die Frage, wie man auf einen SQL-Server zugreifen will.

Variante 1) ODBCDBE - verhält sich (fast) wie eine normale DBF-Datei und sollte nur mit geringen Code-Änderungen umsetzbar sein;
Variante 2) SQLExpress - bietet deutlich mehr Möglichkeiten, erfordert aber einen deutlich höheren Änderungsaufwand.

Beide Varianten setzen auf dem jeweiligen ODBC-Treiber auf.

Variante 3) MySQL mit dem Wrapper von Hector Peroza (setze ich ein), der Änderungsaufwand liegt im Bereich von SQLExpress;
Variante 4) PostgreSQL mit dem Wrapper von Hector Peroza, der Änderungsaufwand liegt im Bereich von SQLExpress;

Beide Varianten setzen auf der C-API des jeweiligen SQL-Server auf und sollten daher einen Tick schneller sein als die ODBC-Varianten. Die ODBC-Variante redet mit dem ODBC-Treiber, der mit der C-API, die mit dem Server. Das sind vier Stationen. Der Wrapper redet direkt mit der C-API, damit fällt eine Station raus.

Dazu kommt die Frage, wie "intelligent" der ODBC-Treiber umgesetzt ist. Wenn er beispielsweise alle Sätze aus einem grossen SELECT liest, bevor die Steuerung an das Programm zurückgeht, kann das schon einen Performance-Einbruch bedeuten.


Wenn Du jetzt mit MsSQL arbeiten willst, wirst Du wahrscheinlich auf Variante 1 oder Variante 2 zurückgreifen müssen. Mir ist zumindest nicht bekannt, dass es einen Wrapper für die C-API des MsSQL-Servers gibt.

Kleiner Nachtrag: wenn 2 Arbeitsplätze gleichzeitig zugreifen braucht jeder Rechner ca. 35 Sekunden um einen Auftrag anzuzeigen, unter CL 5.2 immer weit unter 1 Sekunde!
Du beziehst Dich hier auf Standard-DBE-Zugriffe mit Xbase++? Das habe ich selbst mit 1.8 und 100 MBit-Netzwerk nicht erlebt, das geht deutlich schneller. Ich würde hier andere Ursachen vermuten.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
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: Der Weg zu SQL?

Beitrag von satmax »

Nachtrag: auch wenn ich die Daten und Programm am Netz liegen habe und ich das Programm 3 mal auf einem PC starte passt alles. Erst wenn ein 2 PC dazukommt wird es schlimm. Ausgenommen das Notebook mit WLAN, aber das lasse ich mal außen vor,
Gruß
Markus
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: Der Weg zu SQL?

Beitrag von satmax »

georg hat geschrieben:Hallo,
Variante 1) ODBCDBE - verhält sich (fast) wie eine normale DBF-Datei und sollte nur mit geringen Code-Änderungen umsetzbar sein;
Variante 2) SQLExpress - bietet deutlich mehr Möglichkeiten, erfordert aber einen deutlich höheren Änderungsaufwand.
Beide Varianten setzen auf dem jeweiligen ODBC-Treiber auf.
Eventuell eine Variante aus beiden? ODBCDBE um alles schnell auf SQL zu haben, SQLExpress um einzelne Teile dann sauber auszuprogrammieren?

Wobei ich ODBCDBE überhaupt nicht kenne, da muss ich mich jetzt mal schlau machen. Gibt es so etwas wie ein "Upsizing Tool" um bestehenden DB's mal schnell in einen SQL Server zu bekommen?


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

Re: Der Weg zu SQL?

Beitrag von brandelh »

Ich würde keinesfalls beides mischen !

Die ODBCDBE erhält man mit der Prof. Sub, dagegen ist SQLexpress fast geschenkt und auf jeden Fall seinen Preis wert ;-)

Die ODBCDBE verhält sich fast wie eine FOXDBE/DBFDBE, also die gleiche Syntax: SKIP, REPLACE etc.
Man denkt, man kann viel code einfach so behalten ...

Ich persönlich halte schon seit ich damals bei VO die DBServer() gesehen habe den objekt orientierten Ansatz für besser !

SQLexpress erstellt ein Objekt für die Befehle zum SQL Server, darin wird ausschließlich SQL gesprochen und liefert ein Objekt mit den Daten zurück (Resultset).
Mit dem Datenobjekt arbeitet man dann ... mein größtes Problem war, dass ich meine großen Dateien tatsächlich SATZWEISE vom 1 bis zum letzten durchlaufen muss.
Das habe ich so mit SQL nicht performant hinbekommen, wobei ich nicht sagen will, dass es nicht geht ;-)

Aber normalerweise will man ja gerade nur einen Bruchteil der Daten verarbeiten ohne sich um Indexe, SMB1/2/3 etc. zu kümmern und die Sortierung wird auch gleich vom Server übernommen.

Man merkt, ich bin ein SQLexpress() Verfechter :-)

es ist einfach, stabil und ausgereift.
Es zwingt zum SQL denken und nicht zum "wir wurschteln alles zusammen und egal ob CSV, DBF oder SQL-Server - Xbase weiß am Besten wie es geht ..."

Das mit CSV konnte ich mir nicht verkneifen, da ich mich seit Jahren ärgere, dass ein einfaches append from SDF nicht mehr so geht wie ich es unter Clipper gewohnt war (einfach und stabil) ...
Gruß
Hubert
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: Der Weg zu SQL?

Beitrag von georg »

Hallo,


allerdings greift SQLExpress zumindest im Zugriff auf MySQL und PostgreSQL zu kurz, da SQLExpress nur die Befehle abbilden kann, die über entsprechende SQL-Statements ausgeführt werden können.

Bei MySQL gibt es z.B. die Möglichkeit, den letzten automatisch erzeugten Primary Key (Claus PRIMARY KEY AUTO_INCREMENT) abzufragen.

Wenn der Ziel-Server ein MsSQL-Server ist, gibt es kaum eine Alternative zu SQLExpress.

Übrigens setze ich SQLExpress auch seit Jahren ein.
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: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Der Weg zu SQL?

Beitrag von brandelh »

georg hat geschrieben:allerdings greift SQLExpress zumindest im Zugriff auf MySQL und PostgreSQL zu kurz, da SQLExpress nur die Befehle abbilden kann, die über entsprechende SQL-Statements ausgeführt werden können.
Bei MySQL gibt es z.B. die Möglichkeit, den letzten automatisch erzeugten Primary Key (Claus PRIMARY KEY AUTO_INCREMENT) abzufragen.
dazu gibt es die SQL Funktion LAST_INSERT_ID() ... :arrow: http://www.xbaseforum.de/viewtopic.php?f=88&t=6947

Phil hatte vor Jahren die Vorteile der direkten C-API gepriesen, weil er mehr Kontrolle über den PostGreSQL Server brauchte.
Ich brauche das nicht und ziehe die Flexibilität bei der Serverwahl vor. So und nu ... :coffee:
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: Der Weg zu SQL?

Beitrag von Tom »

Das geschilderte Problem muss andere Ursachen haben. Solche Latenzen sind auch bei DBFNTX/FOXCDX ungewöhnlich. Ich würde mal im Code schrittweise tracken, welche Prozesse so viel Zeit benötigen. Und ich würde ergänzend überwachen, was bei Dateizugriffen auf dem Server geschieht.
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Der Weg zu SQL?

Beitrag von brandelh »

da kann ich TOM nur zustimmen.
Gruß
Hubert
Benutzeravatar
Markus Walter
Programmier-Gott
Programmier-Gott
Beiträge: 1018
Registriert: Di, 24. Jan 2006 10:22
Wohnort: Saarland

Re: Der Weg zu SQL?

Beitrag von Markus Walter »

Hi,

ich sehe das ebenso wie Tom. In der Tat bringt das Netzwerk (leider) deutliche Latenzen gegenüber dem lokalen Zugriff (je nach Aktion bis Faktor 10, Xbase++ braucht übrigens für manche Aktionen auch doppelt solange wie Clipper), aber die von Dir genannten Werte müssen andere Ursachen haben. Wir arbeiten mit DBF/CDX/FPT auch in Netzwerken mit >20 Usern im gleichzeitigen Zugriff und die Geschwindigkeitseinbußen liegen bei weitem nicht in den von Dir genannten Bereichen.

Ein (typisches) Problem könnte in Deinem Falle aktives Opportunistic Locking sein. Such mal hier im Forum danach (oder nach OP locking). Aber Achtung, da sind in der Vergangenheit schon Glaubenskriege entbrannt und werden jetzt wieder entfesselt... ;-) Ich schalte nach wie vor OPLocks aus. Dann ist zwar der exklusive Zugriff über Netz langsamer als mit aktivierten OPLocks, aber bei mehreren Arbeitsplätzen gibt es keine weiteren nenennswerten Einbußen mehr.
Gruß
Markus

Mitglied der XUG Saarland-Pfalz
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Der Weg zu SQL?

Beitrag von brandelh »

Hier sind die Keys, wie sie bei uns gesetzt sind (von den Profi-Admins, nicht nur wegen meiner Xbase++ Anwendungen ...):

SERVER: ... OS: Windows Server 2008 06.01 Build 07601 Service Pack 1

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters
- OplocksDisabled = 1
- InfoCacheLevel = NIL // wenn man hier 10 hex oder 16 einträgt, werden auch lange Dateinamen gecached (schneller gefunden)

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
- EnableOplocks = NIL // gibt es diesen Zweig überhaupt bei 2008er Server (bzw. Win 7 Rechner) ?

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters
- DisableFlushOnCleanup = NIL // keine Ahnung was das sollte ?
- FileInfoCacheLifetime = 0 // *** ganz wichtig ab Win 7 ff.
- FileNotFoundCacheLifetime = 0
- DirectoryCacheLifetime = 0

die Werte sind REG_DWORD ...
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: Der Weg zu SQL?

Beitrag von satmax »

@ALL

Danke für Eure zahlreichen Antworten. Ich werde versuchen das abzuarbeiten und die Ursache zu finden.

Ich muss jetzt aber nochmals das Thema SQL aufgreifen, Hintergrund: ich habe einen Softwareentwickler der in VC++ und SQL Server programmiert, dazu zwei Programmpakete unter VC++ die laufend von Ihm weiterentwickelt werden. Ich habe einen fertigen Datenimport der DBF in einen MS SQL DB sowie ein Auswerteprogramm das diese Daten dann auswertet. Alles von meinem Programmierer gemacht.

Der Plan war, auch dieses CL 5.2 Programm nach VC+ und SQL Server umzusetzen (alle drei Programme haben überschneidende Stammdaten). Da aber mein Programmierer ständig mit diesen beiden anderen Projekten voll ausgelastet ist habe ich mich entschlossen das Clipper Programm selbst zu portieren da es sonst nie fertig wird. In der kurzen geplanten Zeit schien mir eine Portierung mit VC++ unmöglich da ich damit bisher kaum gearbeitet habe. Mit Xbase++ ging es eigentlich sehr zügig voran, das ich sogar leicht vor meinem Zeitplan liege. Eben weil ich unter Xbase++ viel von meinem Clipper Knowhow einbringen konnte.

Vor 2 Monaten hätte ich mir eine gleichzeitige SQL Umsetzung (Xbase++ und SQL) in dieser Zeit einfach nicht zugetraut. Jetzt wo ca. 2/3 unter Xbase++ umgesetzt ist schätze ich die Lage etwas anders ein. Und ein SQL Server ist einfach stabiler.

Die Frage ist jetzt Primär, mit welchem System gehe ich an die Sache ran.

Grob geschätzt würde es mit ODBCDBE relativ schnell gehen und nach ca. 2 Wochen sollte schon wieder einiges von dem bisher programmierten unter MSSQL laufen. Und mein Ziel bis Jahresende eine 90% fertige Version zu haben ist weiterhin erreichbar. Wenn also ODBCDBE richtig funktioniert wäre es IMHO die optimale Lösung für mich. Nur, langsamer als DBF/CDX darf es wirklich nicht werden.

Mit SQLExpress kann ich überhaupt keine Schätzung abgeben und das macht es schwierig. Demo gibt es leider von beiden nicht.


Gruß
Markus
Gruß
Markus
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: Der Weg zu SQL?

Beitrag von satmax »

brandelh hat geschrieben:Hier sind die Keys, wie sie bei uns gesetzt sind (von den Profi-Admins, nicht nur wegen meiner Xbase++ Anwendungen ...):

SERVER: ... OS: Windows Server 2008 06.01 Build 07601 Service Pack 1

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters
- OplocksDisabled = 1
- InfoCacheLevel = NIL // wenn man hier 10 hex oder 16 einträgt, werden auch lange Dateinamen gecached (schneller gefunden)

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
- EnableOplocks = NIL // gibt es diesen Zweig überhaupt bei 2008er Server (bzw. Win 7 Rechner) ?

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters
- DisableFlushOnCleanup = NIL // keine Ahnung was das sollte ?
- FileInfoCacheLifetime = 0 // *** ganz wichtig ab Win 7 ff.
- FileNotFoundCacheLifetime = 0
- DirectoryCacheLifetime = 0

die Werte sind REG_DWORD ...
Hallo Hubert,

zwei Fragen dazu:
1) all diese Werte am Server oder/und auch auf den Workstations?
2) NIL kann aber kein DWORD sein, nehme ich hier "Zeichenfolge"?


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

Re: Der Weg zu SQL?

Beitrag von brandelh »

Sorry für die dürftige Info ;-)

Ich frage die Einträge ab und NIL bedeutet nur, dass dieser Eintrag auf dem Rechner nicht gesetzt wurde.
ALLE Server Einträge müssen auf die PCs, die Daten zur Verfügung stellen, denn es geht nicht um den SERVER als Rechner, sondern um die Funktion - also die Software - und da sind alle Server die was freigeben.

ALLE Workstation Einträge müssen auf die Workstations, wobei ein Terminal-Server ja auch Client ist (bzw. diese lokal laufen und nur das Bild übermitteln).

Wenn du nach den einzelnen Einträgen hier im Forum suchst, wirst du Abhandlungen zu dem Thema finden ;-)

Auf jeden Fall sind SQL-Server stabiler und wenn du mit SQL Erfahrung hast, dann sind die nicht schwer.

Mit SQLexpress wirst du schnell Erfolge haben UND die Anwendung wird stabil.

:arrow: http://www.sqlexpress.com/menu.htm

und wer behauptet, man kann keine DEMO bekommen ?
Du lädst das komplette Paket, installierst und nutzt es ... die Anwendung wird lediglich ohne Lizenzschlüssel eine kurze MSGBOX anzeigen und nach 30 oder 60 Minuten abschalten.
Ich habe es zwar schon länger nicht probiert (ich habe ja einen Schlüssel), aber so müsste es sein, nur die richtige ZIP für deinen Xbase++ Compiler auswählen.

Boris ist auch sehr hilfsbereit 8)

In den Beispielen findet man Zugriffe auf MDB (Access), XLS, DBF und MsSQL (Northwind oder was) ...

InfoCacheLevel = 10 hex oder 16 dez.
EnableOplocks = 0 // ausschalten, soweit ich mich erinnere, einschalten wäre dann 1 ;-) logisch halt 8)
Gruß
Hubert
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: Der Weg zu SQL?

Beitrag von georg »

Hallo, Markus -


schicke Boris Borzic eine Email und bitte um eine Demo, er stellt sie Dir zur Verfügung.

Grundsätzlich würde ich Dir raten - wenn es um die Alternative ODBCDBE bzw. SQLExpress geht - auf SQLExpress zurückzugreifen, da Du dort mehr Kontrolle über das hast, was passiert.

Bei mir gammelt die ODBCDBE seit Jahren auf der Platte rum und wird nicht gebraucht, während SQLExpress mir sehr gute Dienste leistet, auch z.B. beim Erstellen von Auswertungen in Excel etc.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Antworten