Der Weg zu SQL?

alles was zunächst nicht kategorisierbar ist

Moderator: Moderatoren

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

Beitrag von AUGE_OHR »

satmax hat geschrieben:Zu diesem Zeitpunk wir kein einziger dbRLock() ausgeführt, eigentlich nur ein dbSkip().
das denkst du ... :badgrin:
bei Thema 8999 hab ich doch von meinen Problem in der Xbase++ v1.3x Version erzählt.
wenn wir von locking sprechen beziehen wir und auf die DBF ... und was ist mit dem Index(en) ?

ich habe ja schon mal gesagt das Xbase++ "Dirty Read" anders interpretiert als Cl*pper.
nicht die DBF selbst sondern das locking der/die Index(e) ist der Unterschied.
satmax hat geschrieben:Habe das Programm auch schon per UNC gestartet, mit DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE , LOCKING_EXTENDED ), immer das gleiche.
zusammen mit Cl*pper ? -> NEIN !!!
btw. schalte mal OPTIMIZE OFF

auch wenn Xbase++ nicht gerade die schnellste Sprache ist, aber dein Performance Problem ist extrem.
wenn dein Server auch weiter M$ Produkte verwendet oder als M$ SQL Server läuft ist das ungünstig
für Xbase++ Anwendungen deren DBF / Index(e) auf dem Server liegen.
Es hört sich nach "Ops Locking" Problemen an wo man zunächst mal die von Alaska empfohlenen SMB1 Eingriffe vornehmen sollte.

und immer ALLE beteiligten PCs runter fahren und neu starten ( Server zuerst )

dann solltest du mit einem kleinen Test Programm ( siehe SMB2 Thread ) mittels dual-fähigen Code feststellen wo du die Unterschiede hast.

***

bei SQL fällt ja die gesamte ISAM Navigation weg. über die API oder ODBC wird im Grunde nur die "Kommunikation" abgewickelt.

pgDBE versucht nun als Xbase++ Wrapper die ISAM Befehle in PostgreSQL Query zu übersetzen und abzusenden.
Navigieren im zurück gegebenen Result Set kann man dann mit normalen pgDBE Befehlen wie SKIP.

die angesprochenen "native" Lösungen stellen dir den Zugriff auf die API sowie eine Source Class zum navigieren zur Verfügung.
weiter Info findest du bei Pablo in seinem Forum http://www.xbwin.com -> Forum

SQLexpress++ nutzt den ODBC Weg und bietet wohl den besten Support

egal für welchen SQL Server man sich entscheidet, es wird die Client Applikation sein deren Geschwindigkeit das ganze bestimmt.
die Xbase++ ISAM Denkweise auf SQL umzustellen zwecks Optimierung wird dann zum Problem solange man SQL nicht kennt.
wie bei anderen Sprachen auch muss man die neuen Funktionen erlernen und wie man die am besten verwendet.
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: Der Weg zu SQL?

Beitrag von AUGE_OHR »

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

\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
em, äh ... auf dem Server ?

das hat aber nicht "direkt" mit SMB1 zu tun wie auch :

Server :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanserver\Parameters
autodisconnect : http://support.microsoft.com/kb/219022
Verbindung zum Server Timeout hochsetzten

Improving Performance of MS-DOS Database Applications
SharingViolationDelay : http://support.microsoft.com/kb/150384
SharingViolationRetries : http://support.microsoft.com/kb/150384
USE von Tabelle oder Index dauert lange

Shared file access is delayed if the file is open on another computer
Workstation :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters
UtilizeNtCaching : http://support.microsoft.com/kb/259928
Wenn REPLACE auf dem Server lange dauert -> Empfehlung : DWORD = ´0´

REPLACE Command Runs Slowly When Applied to a Remote Table
DisableFlushOnCleanup : http://support.microsoft.com/kb/825433
DbAppend()/DbCommit() sind langsam -> Empfehlung : DWORD = ´1´

Poor performance when you append data to a shared file-based database from a Windows XP-based client
man sollte also erst mal diese Tips ausprobieren bevor man in einem SMB2 OS() anfängt die "direkten" SMB1 Registry Einträge () zu verändern.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanserver\Parameters
CachedOpenLimit : http://support.microsoft.com/kb/126026
EnableOpLockForceClose : http://support.microsoft.com/kb/102967
EnableOpLocks : http://support.microsoft.com/kb/129202
OplocksDisabled : http://support.microsoft.com/kb/296264

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters
UseLockReadUnlock : http://support.microsoft.com/kb/102981
UseOpportunisticLocking : http://support.microsoft.com/kb/129202
UseUnlockBehind : http://support.microsoft.com/kb/102981
gruss by OHR
Jimmy
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 »

AUGE_OHR hat geschrieben:
brandelh hat geschrieben:SERVER: ... OS: Windows Server 2008 06.01 Build 07601 Service Pack 1

\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
em, äh ... auf dem Server ?
erst richtig lesen und dann meckern :badgrin:
Das ist ein Terminal Server :!:
Und der braucht auch die Workstation Einstellungen, denn die Anwendungen laufen auf diesem ;-)
Im Übrigen stören diese Werte nicht, daher würde ich sie eh auf allen Rechnern gleich halten ... 8)

PS: einige der MSDN Fixes sind genauso alt wie die Hinweise und schon längst auf den Rechnern durch neuere Versionen ersetzt. Keinesfalls in älteres "Hotfix" installieren, sondern dann nur die registry keys verwenden.
Zu Hause habe ich einen X4 Phenon mit 3Ghz mit 8 GB Ram, und wenn ich in Thunderbird schreibe kommt es vor, dass er 5 bis 10 Sekunden total blockiert um dann die Tasten nachzuliefern.
Kein "Diagnose" oder "Rettungs" Tools konnte ein Problem finden, ich werde wohl neu installieren.
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 »

Jetzt habe ich schon meinen ersten "Hänger".

Code: Alles auswählen

 SQLConnection():displayErrors := .f.
   oConn := SQLConnection():new()

   // first try to connect to the MS Access TEST.MDB database, if that fails then
   // display all ODBC data sources available on user's machine and allow user to select one

   if !oConn:driverConnect(nil, cConnectionString, SQL_DRIVER_NOPROMPT) ;
      .and. !oConn:DriverConnect()
      tdMsg("Unable to connect to data source!")
      oConn:destroy()
      Return
   endif

   oDlg:oSbar2:setcaption(""+ oConn:DbmsName + ", Database: "+ oConn:DatabaseName)

   SQLConnection():displayErrors := .t.


oCursor := SQLSelect():new("SELECT * FROM Kunden ORDER BY Name", oConn)
oCursor:Execute()
oCursor:GoTop()
SQL Connection funktioniert, bei oCursor:Execute() kommt der Fehler "ungültiger Objektname 'Kunden'"


Gebe ich die Zeile

SELECT * FROM Kunden ORDER BY Name

direkt in der MMC ein wird Sie einwandfrei verarbeitet und zeigt mir alle Datensätze sortiert nach Name an.

Fehlt da noch etwas?



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 »

auf die Schnelle würde ich in der ersten Zeile die Fehlermeldungen einschalten.
Funktionieren die mitgelieferten Beispiele ?
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 »

Die Beispiel funktionieren. Das Einschalten der Fehlermeldung hat nichts gebracht. oConn:DbmsName und oConn:DatabaseName liefern die richtigen Werte.
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 »

Hier noch etwas genauer:

Windows 7 06.02 Build 09200, SQLXpp: 3.2.15, Runtime: 1.90.355
SQLState: 42S02, ErrorCode:208
[Microsoft][ODBC SQL Server Driver][SQL Server]Ungültiger Objektname 'Kunden'.


42S02: Base table or view not found
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 »

Ich bin ein .....

Geht schon, ich hatte die falsche Database angegeben.


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

Beitrag von AUGE_OHR »

brandelh hat geschrieben:
AUGE_OHR hat geschrieben:em, äh ... auf dem Server ?
Das ist ein Terminal Server :!:
OK
brandelh hat geschrieben:PS: einige der MSDN Fixes sind genauso alt wie die Hinweise und schon längst auf den Rechnern durch neuere Versionen ersetzt.
Keinesfalls in älteres "Hotfix" installieren, sondern dann nur die registry keys verwenden.
es ging mir bei den Links, welche ich vor mehren Jahre erarbeitet habe, nicht um die M$ Hotfixe sondern um die Beschreibung sodas man selbst die Registry Werte kontrollieren kann.

ich habe auch die "direkten" SMB1 Registry Einträge nicht weiter kommentiert was passiert wenn man die in einer SMB2 Umgebung "abstellt"
gruss by OHR
Jimmy
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: Der Weg zu SQL?

Beitrag von Rudolf »

Hallo Markus,
ich habe vor Jahren ein großes Projekt komplett wieder von ODBCDBE auf SQLEXPRESS umschreiben müssen, die OBCDBE hatte zahlreiche Fehler und Alaska hat nur nach langer Zeit und vielen Diskussionen reagiert. Seit dem arbeite ich nur mehr mit SQLEXPESS und hatte nie wieder Probleme, alles läuft perfekt. Wenn Du bestehenden Code umschreiben musst, dann ist es sicher aufwändiger mit SQLEXPRESS, aber es bietet wesentlich mehr Möglichkeiten, ist absout stabil und der Support von Boris ist perfekt. Ich arbeite mit eXpress++, hier werden schon viele Dinge wie z.B. der GUI Browser für SQL Tabellen oder das Get System unterstützt. Wenn Du Beispiel brauchst, kann ich Dir gerne was zusenden.
Grüße
Rudolf
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 »

Danke Rudolf!

Ich habe gestern mit SQLExpress begonnen und bin dabei einfache Stammdaten mal umzusetzen. Ich verwende aber TD, Grundfunktionen für SQL sind auch hier enthalten und Clayton hat mir gestern ein kleines Update geschickt.

Ich kann die Stammdaten bereits anzeigen, blättern, löschen , ändern und neu anlegen. :) Noch keine Suche und keine Verknüpfungen.

Ich habe aber gleich eine Frage, ich verwende:

Code: Alles auswählen

oCursor := SQLSelect():new("SELECT * FROM Adressen ORDER BY Name1", oConn,{AcKeyField})
oCursor:DateTimeAsDate:=.T.
oCursor:SetPrimaryKey( 1, "Adressen"  )//  -> 1. Feld ist in jeder Tabelle ein Auto-PrimaryKey
TopDown hat das Beispiel mit:

Code: Alles auswählen

******* Create DataSet cursor (Cursor = current set of records)
*oCursor := SQLDataSet():new("SELECT * FROM Adressen ORDER BY Name1",oConn,,{AcKeyField},,,,,lDateTimeAsDate)
aufgebaut. Meine Variante ist aber wesentlich schneller : bei SQLSelect() ist die Dauer praktisch nicht messbar, SQLDataSet() braucht gleich mal 1-2 Sekunden.

Was ist da der wesentlich Unterschied? Handel ich mir mit SQLSelect eventuell Probleme ein?

Dann noch etwas, ich soll jetzt eine Child-Tabelle zum Adressdatensatz anzeigen (Browser innerhalb der GET Maske). Mit DBF hatte ich das mit Scope realisert. Mache ich da ein zweites eigenes SQLSelect() oder fasst man das in ein Statement zusammen? Vom Gefühl her würde ich es trennen. Eine Adresse kann 0-x Child Datensätze haben, ein Child muss aber eine Adresse haben. Beim Bearbeiten brauche ich also einzelne Records.


Gruß
Markus
Gruß
Markus
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: Der Weg zu SQL?

Beitrag von Rudolf »

Hallo Markus,
ich verwende SQLDataSet() da es schneller sein sollte laut Doku. Es wird alles in den Speicher geladen, die weitere Verarbeitung geht dann schneller. Es kommt darauf an was man mit den Daten dann macht. Bei kleinen Datenmengen wrüde ich SQLSelect() verwenden, bei größeren die in einem Browser verarbeitet werden SQLDataSet().
Das Anzeigen von Daten aus verschiednene Tabellen geht bei SQL sehr einfach:
SELECT doc.id AS doc_id, doc.name AS doc_name, app.id AS app_id FROM doc,app WHERE doc.app_id = app.id
Grüße
Rudolf

Meine Function für Cursor:

Code: Alles auswählen

function create_cursor(oConn,cSQL,cID,nMod)
******************************************************************
local oCursor,nsuccess
default nMod to 0
if oConn = NIL
     oConn := MyDefaultSQLConnection()
endif
oConn:displayErrors := .f.
if nMod = 0
     oCursor  := SQLDataSet():new(cSQL, oConn,,,,,,.t.,.F.)
else
     oCursor  := SQLDataSet():new(cSQL, oConn,SQL_CONCUR_READ_ONLY,SQL_CURSOR_DYNAMIC,,,,.t.,.F.) // read only
endif
oCursor:QueryTimeout := 10
/*
if !(oCursor:UsePositionDelete .and. oCursor:UsePositionUpdate)
      // this ODBC driver does not support positioned updates or deletes
      // so we need to define a primary key to ensure that the updates and
      // deletes will be applied to the correct rows in the database
      //
      // *NOTE* some ODBC drivers my report that positioned statements
      // are supported when in fact they are not. In this case you will
      // need to set :UsePositionDelete and :UsePositionUpdate to .F.
      // in order to force SQLExpress to generate searched statements
      // with a primary key.

      oCursor:SetPrimaryKey("Field1")
endif
*/
if !empty(cID)
     oCursor:setprimarykey(cID)
endif
nSuccess := oCursor:execute() // don't really need to execute an SQLDataSet, it's just here for consistency
if !empty(oConn:errormessage)
     log_error(timestamplong() + " " + oConn:errormessage,SQL_PROTFILE )
endif
return oCursor

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 vermute du hast bisher 2 DBF, eine für Stammdaten und eine für Clients ... (neben anderen)
So hast du nun im SQL Server auch 2 Tabellen (1:n Verbindung) ... außer du willst alles in einen Browser haben, dann hast du doppelte Stammdatenzeilen. :wink:
Natürlich brauchst du auch 2 Select Befehle ...

Aufpassen muss man mit lost update (2 Stationen speichern kurz nacheinander die Daten im gleichen Satz).
Altmodische Satzsperren vor dem Edit bis nach dem speichern gehen so ja nicht auf einem SQL Server.
Bei meinem Programm ist das kein Problem, wenn aber z.B. in einer FiBu zwei SB das letzte Ersatzteil kurz nacheinander verkaufen und der Bestand auf -1 ist oder ein Kauf gleich verschwindet, dann hat man ein Problem.
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,


der Unterschied ist schnell erklärt:

SQLSelect() erzeugt einen Cursor, der - je nach Implementierung des Servers! - satzweise durch das Result Set geht (manchmal wird auch das gesamte Result Set übertragen);
SQLDataSet() erzeugt einen Cursor, liest alle Daten ein und hält sie im Speicher Deines Programms.

Das sollte gewisse Geschwindigkeitsunterschiede erklären.
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 »

Hallo Georg,

IMHO wäre SQLSelect() vorzuziehen, außer eventuell für Spezielle Anwendungsfälle wie zum Beispiel eine Auswertung die im Speicher noch berechnet wird...


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:
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:
Gut Ding braucht Weile... :) Im Prinzip gibt es da nicht viel zu tun. Das wichtigste bei MS SQL Express ist das man die Management Konsole mit installiert, dann ist es ganz einfach.

Rechte Maustaste auf die entsprechende Datenbank, dann
TASK / SICHERN

entsprechende Datenbank wählen, dann auf Optionen, Menü Script. Das Script in ein neues Fenster schreiben lassen und unter dem gewünschten Namen speichern. Das Script selbst ist ebenfalls ganz simpel:

Code: Alles auswählen

BACKUP DATABASE [MeineDatenbank] TO  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\Backup\MeineDatenbank.bak' WITH  COPY_ONLY,  RETAINDAYS = 10, NOFORMAT, NOINIT,  NAME = N'MeineDatenbank-Vollständig Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO
Wenn also keine MM Konsole installiert ist, kannst das obige Script einfach anpassen (Pfade + DB Name)

Mit Aufgabe Planen das Script zu den gewünschten Zeiten ausführen lassen (am SQL Server). So hast ein Backup der SQL auf der HD. Dieses File kannst beliebig kopieren und somit sichern.
Gruß
Markus
Antworten