dbExpress gubi połączenie do zdalnej bazy MySQL

Taki sam problem miewamy z Delphi dbGo (ADO) i bazą na m$ sql. My go rozwiązujemy stosując named pipe. Ale bywa także i na odwrót. Zdarza się że to właśnie połączenie przez named pipe jest zrywane. Wtedy ustawiamy normalne połączenie. Tak już mamy od 15 lat. I nie mam pojęcia dlaczego named pipe niekiedy się wywala. Bo w większości przypadków działa OK.

Jest tyle lepszych narzędzi do bazy danych (zarówno darmowych jak i płatnych), że nie ma sensu babrać się z ADO DBExpress itp. Polecam FireDAC, UniDAC lub z darmowych ZeosLib i nie będziecie mieć żadnych problemów z połączeniem.

@wolfik nie doczytałeś. @Lookze używa MySQL i DBExpress. Czyli raczej nie używa ADO. A nawet zdaje mi się, że przy DBExpress nie da się użyć ADO. No przynajmniej ja nie wiem, jak to zrobić. I @Lookze ma kłopot z połączeniem. Zdaje mi się, że ten kłopot nie jest związany z Delphi. Ale może tylko mi się zdaje. Ale ja używam ADO. I dbGo do tego ADO. I też miewam kłopoty z połączeniem z bazą danych. Choć to nie jest MySQL, jak u @Lookze, a m$ SQL.

Dodam jeszcze, że często spotykam się, że ludzie nie lubią ADO. No cóż... Zazwyczaj nie umieją go używać. I potem krążą jakieś dziwne oceny. Dla mnie ADO ma jedną bardzo dużą zaletę. Jest pieruńsko stabilne. Nadal. Od 15 lat. Oczywiście to może się zmienić.

sadam2 napisał(a):

Dodam jeszcze, że często spotykam się, że ludzie nie lubią ADO. No cóż... Zazwyczaj nie umieją go używać. I potem krążą jakieś dziwne oceny. Dla mnie ADO ma jedną bardzo dużą zaletę. Jest pieruńsko stabilne. Nadal. Od 15 lat. Oczywiście to może się zmienić.
A dla mnie ADO jest po prostu wolne. Używam w pracy Firebirda. Testowałem połączenie poprzez ADO oraz standardowe komponenty IBX. Niestety w niektórych przypadkach różnica była kolosalna, nie muszę mówić, że na korzyść IBX'ów? Chcesz to poszukaj na forach jest sporo informacji na ten temat. Więc to nie jest tak, że ludzie nie umieją korzystać.

Baza ma około ośmiuset tabel. U największego klienta backup bazy zajmuje już ponad 21 GB. I nie przeniesiemy tego na firebirda. Zresztą na nic innego także nie przeniesiemy. Bo nikt za taką robotę nie zapłaci. A co do wydajności to nie wiem nawet z czym porównać ... Ale gdybym jednak miał przenosić, to na Oracla. Tam można wątkować. I nadal byłoby ADO. Wątkujące.

Ale nie zrozumiałeś mnie. Chodzi mi o to, że na tym samym serwerze bazodanowym, ta sama baza danych. Jednak inna metoda dostępu miałem różne czasy wykonania tych samych zapytań. Mowa np. o 1 000 000 insertów do tabeli. Niestety ADO poległo tu na całej linii.

No tak... Chyba trochę odbiegacie od tematu. Wkurza mnie to, że dysponuję narzędziem za kilkanaście tyś. złotych (RAD Studio Professional), a gdy trzeba napisać soft współpracujący z bazą danych to mam jeszcze coś dokupywać tak jak to proponował woolfik wyżej. Nie lubię używać komponentów firm trzecich bo różnie z tym bywa. Używałem kiedyś AnyDAC i co teraz? Sprzedali się a darmowych, nowych wersji już nie ma. Martwi mnie to co napisał sadam2, że tego typu problemy pojawiają się przy ADO i MS SQL. Tyle linii kodu i przerabiać na ZEOSa? Ech...

nie bardzo wiem o czym mówisz. AnyDac ma do tej pory wersję darmową, która nazywa się FreeDac (albo AnyDac 1.2.11). Potem przez długi czas miało wersję płatną a teraz po prostu jest częścią Embarcadero i jest w RAD Studio w pakiecie (chyba od wersji XE4).
W firmie używaliśmy płatnej wersji a teraz tej z RadStudio. Prywatnie nadal korzystam z FreeDac mimo jego braków.

Wg mnie w ADO, z dużymi, nowymi projektami, ładują się tylko ci, którzy nie wiedzą co czynią. BTW ADO to nie jest "wymysł" Borlanda a jedynie nakładka na MS ActiveX Data Objects. Więc jeśli masz z tym problemy to źle skierowałeś swoje kroki.

Lookze napisał(a):

Tyle linii kodu i przerabiać na ZEOSa? Ech...

Wcale nie musisz dużo robić jest na to kilka sposóbów.

1. Refaktoring
2. Podmiana unita chyba ADOClient na własny. Takie rozwiązanie powoduje, że w twoich unitach dalej używasz TADQuery a w rzeczywistości jest TZQuery
3. Używając WriteProcessMemory podmieniasz klasę w locie. - najbardziej zamotane ale równie skuteczne rozwiązanie co pkt 2.

sadam2 napisał(a):

Jest pieruńsko stabilne. Nadal. Od 15 lat. Oczywiście to może się zmienić.

:D
podobnie jak pierwsze koło czy to znaczy, że do dziś mamy go używać?

Lookze napisał(a):

Wkurza mnie to, że dysponuję narzędziem za kilkanaście tyś. złotych (RAD Studio Professional), a gdy trzeba napisać soft współpracujący z bazą danych to mam jeszcze coś dokupywać tak jak to proponował woolfik wyżej. Nie lubię używać komponentów firm trzecich bo różnie z tym bywa.
Ale pamiętaj, że polityka twórcy RAD Studio jest bardzo dziwna i potrafią zmienić komponenty czy dodatkowe narzędzia. Kiedyś do raportów był QuickReport. W firmie tego używali, napisali dużo bo zaczynali jeszcze w C++ Builder 5. Zachciało się migracji na 2009 i co? Okazuje się, że albo przepisywać dużą ilość raportów na jakieś inne narzędzie albo kupić pełną wersję QuickReport. Zgadnij co zrobili w firmie? Kupili pełną wersję. Tak więc każdy kij ma dwa końce.

abrakadaber napisał(a):

Wg mnie w ADO, z dużymi, nowymi projektami, ładują się tylko ci, którzy nie wiedzą co czynią. BTW ADO to nie jest "wymysł" Borlanda a jedynie nakładka na MS ActiveX Data Objects. Więc jeśli masz z tym problemy to źle skierowałeś swoje kroki.
Zgodzę się z tym w pełni.

woolfik napisał(a):

1. Refaktoring
   Tylko, że w C++ refactoring nie działa wcale, więc trzeba uciec się do zewnętrznego narzędzia :]

woolfik napisał(a):

1. Podmiana unita chyba ADOClient na własny. Takie rozwiązanie powoduje, że w twoich unitach dalej używasz TADQuery a w rzeczywistości jest TZQuery
   A najlepiej by było pisać tak aby aplikacja była wielowarstwowa. Wtedy nie ma problemu z tym. Dane mogą być pobierane z pliku tekstowego, bazy danych, czy nawet serwera www. Jednak tu już trzeba pisać aplikację w takiej architekturze.

sadam2 napisał(a):

podobnie jak pierwsze koło czy to znaczy, że do dziś mamy go używać?
Zdziwiłbys się ilu ludzi ma takie podejście, że jak coś działa od nastu lat, to nie ma co ruszać czy ulepszać.

Ok, podjąłem decyzję. Zrobiłem wczoraj konwersję bazy MySQL do MS SQL (nawet szybko poszło i na razie nie widzę żadnych błędów). Zamiast dbExpress użyję FireDACa. Pierwszy raz z tym robię więc zobaczymy jak mi pójdzie. Przez chwilę zastanawiałem się nad ADO ew. ZEOSem ale spróbuję z FireDAC. Kiedyś używałem AnyDAC więc powinno być ok.