Diskussion zu "Wissensbasis - MySQL Wrapper von Hector Peroz

Alles zum PostgreSQL-Server

Moderator: Moderatoren

Diskussion zu "Wissensbasis - MySQL Wrapper von Hector Peroz

Beitragvon AUGE_OHR » So, 14. Okt 2012 22:14

BrandelH: Es geht um diesen Thread:
:arrow: viewtopic.php?f=16&t=6624&p=75733#p75733

Bravo =D>

für PostgreSQL gilt praktisch das selbe wie für MySQL was auch die "Wrapper" betrifft wie Hubert ja fragte.
es sind ja 2 Teile : "Wrapper" für die DLL (LIBMYSQL.PRG) und eine "RESULT SET" Class (XBMYSQL.PRG ) die das "navigieren" erlaubt.
man "könnte" die "RESULT SET" Class theoretisch für verschiedene DLL "Wrapper" (XBPGSQL.DLL) verwenden ... aber es gibt eben auch Besonderheiten.

Frage : wollen wir in diesem Thread auch die Unterschiede zu PostgreSQL besprechen ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: MySQL Wrapper von Hector Peroza

Beitragvon georg » Mo, 15. Okt 2012 6:14

Hallo, Jimmy -


da ich derzeit nur MySQL einsetze (neben SQLite), habe ich mich mit den PostGRE-Wrappern nicht beschäftigt, ich fände es aber sinnvoll, ein eigenes Thema zu PostGRE aufzumachen, damit es für mitlesende Dritte übersichtlich bleibt: hier MySQL, dort PostGRE.
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1769
Registriert: Fr, 08. Feb 2008 21:29

Re: MySQL Wrapper von Hector Peroza

Beitragvon brandelh » Mo, 15. Okt 2012 7:14

Hi,

Einen Thread für PostgreSQL, einen für MySQL und einen für SQLite wäre am sinnvollsten.
Wenn es dann gelingt die Unterschiede auf Xbase++ Seite so gering wie möglich zu halten, umso besser.
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: MySQL Wrapper von Hector Peroza

Beitragvon AUGE_OHR » Mi, 17. Okt 2012 5:26

hi,

es ist mir klar das diesee Thread vom MySQL handelt. Ich meine "wenn" es zu einem Punkt kommt "wo" es Unterschiede gibt.

MySQL hat z.B. "autoincrement" was PostgreSQL nicht hat sondern per "Sequence" arbeitet.

so was in der Art meine ich.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: MySQL Wrapper von Hector Peroza

Beitragvon brandelh » Mi, 17. Okt 2012 8:17

Was haltet Ihr davon, dass wir (ich) im passenden Forum einen "Diskussionsthread zu ..." erstelle,
oben im ersten Beitrag auf diesen verweise und die Fragen und Antworten dazu verschiebe ?
So wird das in anderen Foren gemacht um den eigentlichen Beitrag kompakter zu halten und somit leichter lesbar.
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: MySQL Wrapper von Hector Peroza

Beitragvon AUGE_OHR » Mi, 17. Okt 2012 21:44

brandelh hat geschrieben:Was haltet Ihr davon, dass wir (ich) im passenden Forum einen "Diskussionsthread zu ..." erstelle,
oben im ersten Beitrag auf diesen verweise und die Fragen und Antworten dazu verschiebe ?
So wird das in anderen Foren gemacht um den eigentlichen Beitrag kompakter zu halten und somit leichter lesbar.
ja gute Idee.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon brandelh » Fr, 26. Okt 2012 22:28

so erledigt, die Verweislinks habe ich oben im ersten Beitrag eingefügt ;-)
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon AUGE_OHR » So, 28. Okt 2012 6:51

ich fange einfach mal an was mir einfällt ... Korrekturen ausdrücklich erwünscht !

MySQL Field "autoincrement" - PostgreSQL Field "serial"
Zweck : Field was eindeutiges ( UNIQUE ) "rauf-zählt" z.b. für eine "Record Nummer"

pgDBE verwendet intern ein Field "__record" Type "serial" welches als "PRIMARY KEY" definiert wird.
Code: Alles auswählen
   cQuery := "CREATE TABLE " + xtab + " ( "

   i := 1
   aStrut := DBSTRUCT()         // Import DBF
   FOR i = 1 TO LEN( aStrut )
      cQuery += aStrut[ i, 1 ]
      DO CASE
         CASE aStrut[ i, 2 ] = "C"
            cQuery += " character(" + ALLTRIM( STR( aStrut[ i, 3 ] ) ) + "), "
         CASE aStrut[ i, 2 ] = "N"
            cQuery += " numeric(" + ALLTRIM( STR( aStrut[ i, 3 ] ) ) + ',' + ALLTRIM( STR( aStrut[ i, 4 ] ) ) + "), "
         CASE aStrut[ i, 2 ] = "D"
            cQuery += " date, "
         CASE aStrut[ i, 2 ] = "M"
            IF ::lBlob = .T.
               cQuery += " bytea, "
            ELSE
               cQuery += " text, "
            ENDIF
         CASE aStrut[ i, 2 ] = "L"
            cQuery += " boolean, "
         CASE aStrut[ i, 2 ] = "V"               // store as HEX String
            cQuery += " bytea, "
      ENDCASE
   NEXT

   //
   // add "internal" Fields for pgDBE
   //
   cQuery += " __record     serial  NOT NULL, "

   //
   // CONSTRAINT
   //
   cQuery += " CONSTRAINT " + xtab + "_pkey PRIMARY KEY (__record)"
   
   cQuery += " )"                                           // close Query

   oPG:exec( cQuery )
   IF ResultStatus( oPG, oMain )
bei Verwendung des Type "serial" wird automatisch eine "Sequence" angelegt hier "___record_seq"

wenn ich an eine solche Table nun Daten mit "INSERT" einfüge muss ich ein Field "serial" auf diese Weise "incrementieren"
Code: Alles auswählen
  cPreText := "INSERT INTO " + xtab + " VALUES("
   DO WHILE .NOT. EOF()
      cIns := cPreText

      FOR i = 1 TO LEN( aStrut )
            // Type "C","N","D","L","M"
      NEXT
      cIns += "nextval('" + xtab + "___record_seq')" + ","  // use Sequence/nextval()
die PostgreSQL "interne" Function nextval() gibt mir nun die "nächst höhere" ( normal +1) ID zurück ... "eindeutig"

Frage : wie würde man unter MySQL eine Field "_record" mit einer laufenden Nummer definieren ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon georg » So, 28. Okt 2012 7:30

Hallo, Jimmy -


Code: Alles auswählen
CREATE TABLE MeineTabelle (Feld1 Char(32), Feld2 INT, Feld3 TEXT, PRIMARY KEY Feld2 AUTO_INCREMENT)


Es kann pro Tabelle nur ein AUTO_INCREMENT Feld geben, und diese Attribut muss mit PRIMARY KEY verknüpft sein.

Dieses Attribut kann einem INTeger oder FLOAT Feld zugewiesen werden.

Und wie wird dieser Wert gebildet:

Typically this is value+1, where value is the largest value for the column currently in the table. AUTO_INCREMENT sequences begin with 1.

Quelle: http://dev.mysql.com/doc/refman/5.5/en/ ... table.html


Das funktioniert, solange Du der entsprechenden Spalte beim Hinzufügen keinen Wert (also Null) zuweist. Andernfalls - wenn der Wert als Primary Key akzeptable ist - setzt Du einen neuen Anfangswert:

Code: Alles auswählen
INSERT INTO MeineTabelle VALUES('Peter', 0, 'heute') => Feld2 = 1
INSERT INTO MeineTabelle VALUES('Klaus', 0, 'morgen') => Feld 2 = 2
INSERT INTO MeineTabelle VALUES('Martin', 33, 'irgendwann') => Feld2 = 33
INSERT INTO MeineTabelle VALUES('Holger', 0, 'gestern') => Feld2 = 34


Dazu kommt, dass keine Reorganisation dieser Felder stattfindet, wenn ein Datensatz gelöscht wird, werden die Felder in "nachfolgenden" Sätzen nicht automatisch um 1 reduziert.
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1769
Registriert: Fr, 08. Feb 2008 21:29

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon AUGE_OHR » So, 28. Okt 2012 7:31

hi,

ich lese gerade MySQL sein, ohne Modifikationen, nicht Xbase++ Thread fähig ?

ist das Resultset "Problem" nicht eher ein "Connection" Problem ?

bei PostgreSQL läufen mein Browse in verschiedenen Xbase++ Threads wobei ich für jeden Thread eine "eigene Connection" verwende.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon AUGE_OHR » So, 28. Okt 2012 7:36

hi,

danke für den Vergleich, da hätten wir ja schon mal einen Punkt erarbeitet.
georg hat geschrieben:... setzt Du einen neuen Anfangswert:
ah ja ... so was gibt es in Postgre ...
Code: Alles auswählen
setval(text, bigint)  // aktuellen Wert der Sequenz setzen
und die "aktuelle" ID wäre
Code: Alles auswählen
currval(text)   // Wert, der zuletzt durch nextval erzeugt wurde

georg hat geschrieben:Dazu kommt, dass keine Reorganisation dieser Felder stattfindet, wenn ein Datensatz gelöscht wird, werden die Felder in "nachfolgenden" Sätzen nicht automatisch um 1 reduziert.
ja ... daran muss man sich gewöhnen ...
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon georg » So, 28. Okt 2012 13:05

Hallo, Jimmy -

AUGE_OHR hat geschrieben:hi,

ich lese gerade MySQL sein, ohne Modifikationen, nicht Xbase++ Thread fähig ?


das habe ich nicht geschrieben. Bitte lies genau, was ich schreibe.

Man kann - da der Quellcode ja vorliegt - seine eigene MySQL-Version erstellen. Und da gibt es - wie auch bei SQLite etc. - verschiedene Schalter, die gesetzt werden können. Standardmässig ist thread_safe aktiviert. Die Methode zur Überprüfung macht dann Sinn, wenn man Kunden hat, die eine eigenen MySQL-Version einsetzen - auf diesem Wege kann man zur Programmstart feststellen "hier können Probleme entstehen".

AUGE_OHR hat geschrieben:ist das Resultset "Problem" nicht eher ein "Connection" Problem ?

bei PostgreSQL läufen mein Browse in verschiedenen Xbase++ Threads wobei ich für jeden Thread eine "eigene Connection" verwende.


MySQL verlangt - so verstehe ich zumindest die Dokumentation - dass thread_init() und thread_end() aufgerufen werden, es steht dort nichts, dass eine separate Verbindung hergestellt werden muss. Aber welche Dokumentation ist schon vollständig?

Meine Programme verwenden auch mehrere Threads, und sie liefen - bevor ich thread_init() thread_end() implementiert habe - auch stabil, mit nur einer Verbindung.

Daher auch mein Überlegung: ist ein Xbase-Thread tatsächlich ein Windows Thread?
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1769
Registriert: Fr, 08. Feb 2008 21:29

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon AUGE_OHR » Mo, 29. Okt 2012 3:15

georg hat geschrieben:MySQL verlangt - so verstehe ich zumindest die Dokumentation - dass thread_init() und thread_end() aufgerufen werden, es steht dort nichts, dass eine separate Verbindung hergestellt werden muss. Aber welche Dokumentation ist schon vollständig?

Meine Programme verwenden auch mehrere Threads, und sie liefen - bevor ich thread_init() thread_end() implementiert habe - auch stabil, mit nur einer Verbindung.
ok ich habe die Frage, auf PostgreSQL gezogen, mal ins PG-Forum gestellt http://www.pg-forum.de

georg hat geschrieben:Daher auch mein Überlegung: ist ein Xbase-Thread tatsächlich ein Windows Thread?
nö ... ein OS/2 Thread ... ;)
Windows Threads können "verschiedene" CPUs nutzen ... das konnte OS/2 nicht und Xbase++ "deshalb" auch nicht.
wie das "technisch" funktioniert muss ich nochmal Pablo fragen ... er hatte mal "versucht" es mir zu erklären...
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon georg » Mo, 29. Okt 2012 4:53

Guten Morgen, Jimmy -


das würde mich mal interessieren, wäre also nett, wenn Du das in Erfahrung bringen könntest.
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1769
Registriert: Fr, 08. Feb 2008 21:29

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon brandelh » Mo, 29. Okt 2012 8:47

AUGE_OHR hat geschrieben:Windows Threads können "verschiedene" CPUs nutzen ... das konnte OS/2 nicht und Xbase++ "deshalb" auch nicht.
wie das "technisch" funktioniert muss ich nochmal Pablo fragen ... er hatte mal "versucht" es mir zu erklären...

das ist ein mehr als ausgelatschtes Thema :!:
Natürlich sind es Windowsthreads, da diese auf Windows laufen, OS/2 Threads gibt es nur unter OS/2 ...
Und selbstverständlich kann man die EXE so erstellen, dass die Anwendung alle CPUs nutzt.
Dabei gibt es nur ein Problem, die Verarbeitungsgeschwindigkeit sinkt stark, weil die Threads nicht unabhängig von einander sind.
GUI, MAIN, da war noch einer der mir jetzt nicht einfällt und eigene Threads müssen häufig untereinander Infos austauschen und das geht nur schnell,
wenn alles Threads auf dem selben Kern laufen. Daher wird in der EXE fix die erste CPU (der erste Kern) eingestellt.

PS: dass beim Zugriff auf die DLL auch ohne den Aufruf von Thread-Funktionen keine Fehler aufgetreten sind,
könnte an zu wenig Workload oder an der Art des Zugriffs auf fremde DLL liegen (serialisiert ? jeweils nur aus main ?) ...
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon georg » Mo, 29. Okt 2012 8:58

Guten Morgen, Hubert -


hier kann ich immer wieder noch darauf hinweisen, dass es sich um meine Beobachtungen handelt. Und ich habe den Eindruck (wohl eher ein Bauchgefühl), dass Xbase++ Threads quasi "intern" realisiert und nicht auf Windows APIs zu diesem Zweck zurückgreift,

Für uns als Programmierer "sieht es so aus", aber Deine Hinweise auf die Interaktion der Threads deuten mir ebenfalls in diese Richtung.

Und, nein, ich habe keinen serialisierten Zugriff, und die Datenzugriffe sind teilweise sehr massiv, und ich arbeite in allen Threads mit der gleichen Verbindung. Und langsam reizt es mich, mal zu sehen, was _thread_init() eigentlich treibt ...
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1769
Registriert: Fr, 08. Feb 2008 21:29

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon brandelh » Mo, 29. Okt 2012 9:04

georg hat geschrieben:und ich arbeite in allen Threads mit der gleichen Verbindung.

Ich denke, dass dies die Serialisierung automatisch erledigt, da ja nicht zwei Anforderungen gleichzeitig möglich sind.
Normalerweise würde jeder Thread eine eigene Verbindung öffnen und dann könnte es sein, dass mehrere Threads gleichzeitig auf die DLL zugreifen,
was diese durch fixe reentrend sicherere Funktionen berücksichtigen muss. Das grundsätzlich zu tun ist natürlich sowieso besser ;-)
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon AUGE_OHR » Mo, 29. Okt 2012 21:01

brandelh hat geschrieben:Und selbstverständlich kann man die EXE so erstellen, dass die Anwendung alle CPUs nutzt.
:shock: und "wie" ???
das mit OS/2 war "NICHT" als Scherz gemeint ... "das" ist genau "dass" Problem was immer noch aus der OS/2 Zeit stammt ( wie so einiges in Xbase++ )
Das die "Kommunikation" zwischen Threads "Zeit" kostet ist klar, aber Xbase++ läuft ja eh schon auf "höherer Priorität" als normal. Es ist ein Xbase++ "Problem" ( was auf OS/2 beruht ).

zu PostgreSQL diese Information aus dem PG-Forum :
http://www.postgresql.org/docs/current/static/libpq-threading.html
libpq is reentrant and thread-safe by default.
und dass wegen "jeder Thread bekommt seine eigene Connenction"
One thread restriction is that no two threads attempt to manipulate the same PGconn object at the same time. In particular, you cannot issue concurrent commands from different threads through the same connection object. (If you need to run concurrent commands, use multiple connections.)
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon brandelh » Mo, 29. Okt 2012 22:55

AUGE_OHR hat geschrieben:
brandelh hat geschrieben:Und selbstverständlich kann man die EXE so erstellen, dass die Anwendung alle CPUs nutzt.
:shock: und "wie" ???


viewtopic.php?f=30&t=799&p=7932

AUGE_OHR hat geschrieben:das mit OS/2 war "NICHT" als Scherz gemeint ... "das" ist genau "dass" Problem was immer noch aus der OS/2 Zeit stammt ( wie so einiges in Xbase++ ) ... aber Xbase++ läuft ja eh schon auf "höherer Priorität" als normal. Es ist ein Xbase++ "Problem" ( was auf OS/2 beruht ).


Sorry, aber ich kann mir einfach nicht vorstellen, dass Alaska das OS/2 Threadsystem in Windows 32 bit nachgebaut hat.
Der Aufwand dafür (falls überhaupt möglich) wäre viel größer als einfach die Windowsthreads zu verwenden.
OS/2 API Teile waren zwar bei NT noch im Code geben (heute ?) aber meines Wissens waren das nur Terminal apps.
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon AUGE_OHR » Di, 30. Okt 2012 5:40

nun zurück zu MySQL thread_init() / thread_end()

ich habe bei Pablo angefragt und er hat dazu schon eine ot4xb fertige Lösung
BTW: ot4xb provide TLS variables in a simple way Tls():VarName := value so you can use to mantain a reference count

CLASS MySqlConnection
EXPORTED:
INLINE METHOD init()
if Tls():mysql_thread_instance_count := NIL
Tls():mysql_thread_instance_count := 1
else
Tls():mysql_thread_instance_count++
end
.... do anything else you may need
return Self
INLINE METHOD Release()
.... do anything you need to destroy the object
Tls():mysql_thread_instance_count--
if Tls():mysql_thread_instance_count < 1
Tls():mysql_thread_instance_count := NIL
@libmysql:mysql_thread_end()
end
return NIL
.... more methods
ENDCLASS

Regards,
Pablo
der ganze Thread in der Newsgroup
news.xbwin.com
ot4xb.public
Threads and MySQL
29.10.2012
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon brandelh » Di, 30. Okt 2012 8:38

AUGE_OHR hat geschrieben:
georg hat geschrieben:MySQL verlangt - so verstehe ich zumindest die Dokumentation - dass thread_init() und thread_end() aufgerufen werden, es steht dort nichts, dass eine separate Verbindung hergestellt werden muss. Aber welche Dokumentation ist schon vollständig?

Meine Programme verwenden auch mehrere Threads, und sie liefen - bevor ich thread_init() thread_end() implementiert habe - auch stabil, mit nur einer Verbindung.
ok ich habe die Frage, auf PostgreSQL gezogen, mal ins PG-Forum gestellt http://www.pg-forum.de


und die Antwort darauf ist eindeutig:

Pablo hat geschrieben:An Xbase++ thread is a windows thread, but must be aware of :
- Xbase++ thread have at least 1 TLS ( Thread Local Storage) vars initialitzed on all threads created by Xbase++
- Before call any Xbase++ function ( even the Xbase++ C API) require this TLS var initzialized on the caller thread
- If you setup a callback using an Xbase++ function ( or any Xbase++ API call) in a thread not created by Xbase++ your app will crash


Xbase++ Threads sind windows threads :!:
Dass sie TLS (Thread Local Storage) haben ist klar, und dass man von außen darauf erst zugreifen kann nachdem dieser initialisiert wurde auch.
Wer will schon von "außen" auf einen Xbase++ Thread zugreifen ;-)
CallBack Routinen, aber die sind ein anderes Thema ...

Hubert hat geschrieben:> The question came up, because MySql docu says this functions have to be used with a multithreaded app, but the tester did not have (see) problems without using it.

Pablo hat geschrieben:mysql_thread_init() is called automatically by mysql_connect() and mysql_real_connect() and some other functions, call it twice do just nothing so no problem.

also wird die Syncronisation automatisch aufgerufen, es wäre ja nicht wirklich sinnvoll dass jeder Entwickler das falsch machen dürfte :D
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon AUGE_OHR » Mi, 31. Okt 2012 1:14

brandelh hat geschrieben:und die Antwort darauf ist eindeutig:
du beziehst dich auf INIT und Connect aber das "andere Ende" hast du weggelassen
Forgot to call mysql_thread_end() before the thread terminate will result into a memory leak because the memory used to maintain the thread structures will be abandoned
und dafür ist IMHO Pablos "workaround" gedacht.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitragvon brandelh » Do, 01. Nov 2012 18:29

die Beiträge zu CPU Umschaltung und CPU Überlastung habe ich wie gewünscht verschoben:

:arrow: viewtopic.php?f=86&t=6664
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim


Zurück zu SQL-Server

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast