🚀 go-pugleaf

W dniu 2014-05-15 15:00, pbk++ pisze:
> Witam
>
> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :) mam
> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
> Czy ZEOS ma jakąś przewagę nad dbGo?

Nie. W tym przypadku ZEOS nie ma żadnych przewag.
To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
lub Lazarus(owców).

> Jak jest ze wsparciem dla C++ Builder-a?

W RAD STUDIO można utworzyć biblioteki do C++ i pisać w nim(testowałem).
Z tego wynika że istnieje możliwość zainstalowania go do samodzielnego 
BCB tylko trzeba popełnić zestaw stosownych pakietów instalacyjnych(w 
czym nie mam doświadczenia). Można się pewnie posiłkować przykładowym
pakietem cbuilder12.

miab

W dniu 2014-05-15 15:47, miab pisze:
> W dniu 2014-05-15 15:00, pbk++ pisze:
>> Witam
>>
>> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :) mam
>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>> Czy ZEOS ma jakąś przewagę nad dbGo?
>
> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
> lub Lazarus(owców).
Ale Ty tak poważnie? ;-)
Zwłaszcza chodzi mi o to zdanie: "To taki dość ograniczony i 
funkcjonalnie i wydajnościowo dodatek."
Naprawdę ZEOS jest ograniczonym dodatkiem do MSSQL'a czy obsługa MSSQLa 
jest ograniczona (funkcjonalnie i wydajnościowo) w ZEOS?
A moż to po prostu sarkazm jest? :-)

/ciach/

-- 
wloochacz

W dniu 2014-05-15 15:47, miab pisze:
> W dniu 2014-05-15 15:00, pbk++ pisze:
>> Witam
>>
>> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :) mam
>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>> Czy ZEOS ma jakąś przewagę nad dbGo?
>
> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
> lub Lazarus(owców).

Oczywiście mam na myśli ADO w ZEOS-ie. Może służyć np. do importu
formatów M$-a lub/i dalej przez ODBC innych.
Natomiast ZEOS do łączenia z M$SQL może używać też freetds i  wtedy jest 
przewaga bo działa to i w Windows i w Linux-ie w 32 i 64 bitach.

miab

W dniu 2014-05-15 15:58, wloochacz pisze:
> W dniu 2014-05-15 15:47, miab pisze:
>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>> Witam
>>>
>>> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :) mam
>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>
>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>> lub Lazarus(owców).
> Ale Ty tak poważnie? ;-)
> Zwłaszcza chodzi mi o to zdanie: "To taki dość ograniczony i
> funkcjonalnie i wydajnościowo dodatek."
> Naprawdę ZEOS jest ograniczonym dodatkiem do MSSQL'a czy obsługa MSSQLa
> jest ograniczona (funkcjonalnie i wydajnościowo) w ZEOS?
> A moż to po prostu sarkazm jest? :-)

Zupełnie coś innego. Mówię o połączeniu przez ADO w ZEOS-ie.

miab

> > Jak jest ze wsparciem dla C++ Builder-a?
>
> W RAD STUDIO można utworzyć biblioteki do C++ i pisać w nim(testowałem).
> Z tego wynika że istnieje możliwość zainstalowania go do samodzielnego BCB tylko trzeba popełnić 
> zestaw stosownych pakietów instalacyjnych(w czym nie mam doświadczenia). Można się pewnie 
> posiłkować przykładowym
> pakietem cbuilder12.

Jak masz pakiety *.dpk utworzone w Delphi, to dla C++Buildera nie trzeba nic nowego tworzyć.
Wystarczy przekompilować te pakiety z dodatkowymi przełącznikami, żeby utworzyły się pliki
*.hpp i *.bpi. Plik *.bpl jest wtedy wspólny dla Delphi i C++Buildera.

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547 

W dniu 2014-05-15 20:37, Krzysztof Szyszka pisze:
>> > Jak jest ze wsparciem dla C++ Builder-a?
>>
>> W RAD STUDIO można utworzyć biblioteki do C++ i pisać w nim(testowałem).
>> Z tego wynika że istnieje możliwość zainstalowania go do samodzielnego
>> BCB tylko trzeba popełnić zestaw stosownych pakietów instalacyjnych(w
>> czym nie mam doświadczenia). Można się pewnie posiłkować przykładowym
>> pakietem cbuilder12.
>
> Jak masz pakiety *.dpk utworzone w Delphi, to dla C++Buildera nie trzeba
> nic nowego tworzyć.
> Wystarczy przekompilować te pakiety z dodatkowymi przełącznikami, żeby
> utworzyły się pliki
> *.hpp i *.bpi. Plik *.bpl jest wtedy wspólny dla Delphi i C++Buildera.
>

Mówisz o gołym BCB bo że w RAD STUDIO tak jest to wiem bo sam tak robię.
A nigdy samego BCB nie miałem/instalowałem.

miab

> Mówisz o gołym BCB bo że w RAD STUDIO tak jest to wiem bo sam tak robię.
> A nigdy samego BCB nie miałem/instalowałem.

Skompilować musisz w Delphi, ale utworzony plik *.bpl możesz zainstalować mając samo BCB.
Wszystkie inne pliki potrzebne pod BCB (*.hpp, *.bpi, *.lib) również zostaną utworzone podczas
kompilacji pod Delphi. Zobacz jak są instalowane moje pakiety, gdy wybierzesz samo Delphi lub
samo BCB. Niektóre pliki są po prostu wspólne. Tak jest od dawna tworzony cały VCL.

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547 

W dniu 2014-05-15 16:03, miab pisze:
> W dniu 2014-05-15 15:58, wloochacz pisze:
>> W dniu 2014-05-15 15:47, miab pisze:
>>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>>> Witam
>>>>
>>>> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :) mam
>>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>>
>>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>>> lub Lazarus(owców).
>> Ale Ty tak poważnie? ;-)
>> Zwłaszcza chodzi mi o to zdanie: "To taki dość ograniczony i
>> funkcjonalnie i wydajnościowo dodatek."
>> Naprawdę ZEOS jest ograniczonym dodatkiem do MSSQL'a czy obsługa MSSQLa
>> jest ograniczona (funkcjonalnie i wydajnościowo) w ZEOS?
>> A moż to po prostu sarkazm jest? :-)
>
> Zupełnie coś innego. Mówię o połączeniu przez ADO w ZEOS-ie.
No OK, ale OP pytał o coś zupełnie innego...
Nie o ADO w zEOS tylko o porównanie ZEOS vs ADO - a przynajmniej ja to 
tak zrozumiałem...

-- 
wloochacz

W dniu 2014-05-15 20:37, Krzysztof Szyszka pisze:
>> > Jak jest ze wsparciem dla C++ Builder-a?
>>
>> W RAD STUDIO można utworzyć biblioteki do C++ i pisać w nim(testowałem).
>> Z tego wynika że istnieje możliwość zainstalowania go do samodzielnego
>> BCB tylko trzeba popełnić zestaw stosownych pakietów instalacyjnych(w
>> czym nie mam doświadczenia). Można się pewnie posiłkować przykładowym
>> pakietem cbuilder12.
>
> Jak masz pakiety *.dpk utworzone w Delphi, to dla C++Buildera nie trzeba
> nic nowego tworzyć.
> Wystarczy przekompilować te pakiety z dodatkowymi przełącznikami, żeby
> utworzyły się pliki
> *.hpp i *.bpi. Plik *.bpl jest wtedy wspólny dla Delphi i C++Buildera.
>


To to ja wiem. Siedzę w BCB od nastu lat. Tyle, że podjąłem próbę 
instalacji i jak na razie porażka, tj. wszystko się kompiluje, generuje 
header-y i obiekty dla BCB, komponenty są widoczne w Delphi, ale BCB już 
nie. Tj. pakiet jest niby zainstalowany, ale nie widać go na palecie 
komponentów.

Będę próbował raz jeszcze w wolnej chwili.

BCB 2010 Pro

--
Piotrek

W dniu 2014-05-15 16:00, miab pisze:
> W dniu 2014-05-15 15:47, miab pisze:
>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>> Witam
>>>
>>> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :) mam
>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>
>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>> lub Lazarus(owców).
>
> Oczywiście mam na myśli ADO w ZEOS-ie. Może służyć np. do importu
> formatów M$-a lub/i dalej przez ODBC innych.
> Natomiast ZEOS do łączenia z M$SQL może używać też freetds

Nie znam freetds. Muszę obadać.

i  wtedy jest
> przewaga bo działa to i w Windows i w Linux-ie w 32 i 64 bitach.
>

Jaka jest prędkość działania w porównaniu do dbGo?

--
Piotrek

W dniu 2014-05-16 13:24, wloochacz pisze:
> W dniu 2014-05-15 16:03, miab pisze:
.
> Nie o ADO w zEOS tylko o porównanie ZEOS vs ADO - a przynajmniej ja to
> tak zrozumiałem...
>


I o to mi chodziło.

W dniu 2014-05-16 13:24, wloochacz pisze:
> W dniu 2014-05-15 16:03, miab pisze:
>> W dniu 2014-05-15 15:58, wloochacz pisze:
>>> W dniu 2014-05-15 15:47, miab pisze:
>>>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>>>> Witam
>>>>>
>>>>> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :)
>>>>> mam
>>>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>>>
>>>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>>>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>>>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>>>> lub Lazarus(owców).
>>> Ale Ty tak poważnie? ;-)
>>> Zwłaszcza chodzi mi o to zdanie: "To taki dość ograniczony i
>>> funkcjonalnie i wydajnościowo dodatek."
>>> Naprawdę ZEOS jest ograniczonym dodatkiem do MSSQL'a czy obsługa MSSQLa
>>> jest ograniczona (funkcjonalnie i wydajnościowo) w ZEOS?
>>> A moż to po prostu sarkazm jest? :-)
>>
>> Zupełnie coś innego. Mówię o połączeniu przez ADO w ZEOS-ie.
> No OK, ale OP pytał o coś zupełnie innego...
> Nie o ADO w zEOS tylko o porównanie ZEOS vs ADO - a przynajmniej ja to
> tak zrozumiałem...

Pytał o porównanie dbGo i ZEOS.

miab

W dniu 2014-05-16 13:32, pbk++ pisze:
> W dniu 2014-05-15 20:37, Krzysztof Szyszka pisze:
>>> > Jak jest ze wsparciem dla C++ Builder-a?
>>>
>>> W RAD STUDIO można utworzyć biblioteki do C++ i pisać w nim(testowałem).
>>> Z tego wynika że istnieje możliwość zainstalowania go do samodzielnego
>>> BCB tylko trzeba popełnić zestaw stosownych pakietów instalacyjnych(w
>>> czym nie mam doświadczenia). Można się pewnie posiłkować przykładowym
>>> pakietem cbuilder12.
>>
>> Jak masz pakiety *.dpk utworzone w Delphi, to dla C++Buildera nie trzeba
>> nic nowego tworzyć.
>> Wystarczy przekompilować te pakiety z dodatkowymi przełącznikami, żeby
>> utworzyły się pliki
>> *.hpp i *.bpi. Plik *.bpl jest wtedy wspólny dla Delphi i C++Buildera.
>>
>
>
> To to ja wiem. Siedzę w BCB od nastu lat. Tyle, że podjąłem próbę
> instalacji i jak na razie porażka, tj. wszystko się kompiluje, generuje
> header-y i obiekty dla BCB, komponenty są widoczne w Delphi, ale BCB już
> nie. Tj. pakiet jest niby zainstalowany, ale nie widać go na palecie
> komponentów.
>
> Będę próbował raz jeszcze w wolnej chwili.
>
> BCB 2010 Pro

U mnie działa w C++ równolegle z Delphi Pascalem w D2007 i DXE2.

miab

W dniu 2014-05-16 13:33, pbk++ pisze:
> W dniu 2014-05-15 16:00, miab pisze:
>> W dniu 2014-05-15 15:47, miab pisze:
>>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>>> Witam
>>>>
>>>> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :) mam
>>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>>
>>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>>> lub Lazarus(owców).
>>
>> Oczywiście mam na myśli ADO w ZEOS-ie. Może służyć np. do importu
>> formatów M$-a lub/i dalej przez ODBC innych.
>> Natomiast ZEOS do łączenia z M$SQL może używać też freetds
>
> Nie znam freetds. Muszę obadać.
>
> i  wtedy jest
>> przewaga bo działa to i w Windows i w Linux-ie w 32 i 64 bitach.
>>
>
> Jaka jest prędkość działania w porównaniu do dbGo?

Trudno je porównywać bo ADO to cała infrastruktura w systemie a FreeTDS 
to mała biblioteka komunikująca się z serwerem.
W prostych przykładach w ZEOS bywa szybsza i od ZEOS-owego ADO i od 
dbGo, ale miała problemy z unicodem.
Nie wiem jak jest teraz, bo rozwija się zrywami.

miab

W dniu 2014-05-16 13:52, miab pisze:
> W dniu 2014-05-16 13:24, wloochacz pisze:
>> W dniu 2014-05-15 16:03, miab pisze:
>>> W dniu 2014-05-15 15:58, wloochacz pisze:
>>>> W dniu 2014-05-15 15:47, miab pisze:
>>>>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>>>>> Witam
>>>>>>
>>>>>> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :)
>>>>>> mam
>>>>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>>>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>>>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>>>>
>>>>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>>>>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>>>>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>>>>> lub Lazarus(owców).
>>>> Ale Ty tak poważnie? ;-)
>>>> Zwłaszcza chodzi mi o to zdanie: "To taki dość ograniczony i
>>>> funkcjonalnie i wydajnościowo dodatek."
>>>> Naprawdę ZEOS jest ograniczonym dodatkiem do MSSQL'a czy obsługa MSSQLa
>>>> jest ograniczona (funkcjonalnie i wydajnościowo) w ZEOS?
>>>> A moż to po prostu sarkazm jest? :-)
>>>
>>> Zupełnie coś innego. Mówię o połączeniu przez ADO w ZEOS-ie.
>> No OK, ale OP pytał o coś zupełnie innego...
>> Nie o ADO w zEOS tylko o porównanie ZEOS vs ADO - a przynajmniej ja to
>> tak zrozumiałem...
>
> Pytał o porównanie dbGo i ZEOS.
OK.
Powiedz czego nie rozumiesz co tu napisano?
Wg Ciebie dbGo to nie ejst ADO??


-- 
wloochacz

W dniu 2014-05-16 15:13, wloochacz pisze:
> W dniu 2014-05-16 13:52, miab pisze:
>> W dniu 2014-05-16 13:24, wloochacz pisze:
>>> W dniu 2014-05-15 16:03, miab pisze:
>>>> W dniu 2014-05-15 15:58, wloochacz pisze:
>>>>> W dniu 2014-05-15 15:47, miab pisze:
>>>>>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>>>>>> Witam
>>>>>>>
>>>>>>> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :)
>>>>>>> mam
>>>>>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>>>>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>>>>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>>>>>
>>>>>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>>>>>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>>>>>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>>>>>> lub Lazarus(owców).
>>>>> Ale Ty tak poważnie? ;-)
>>>>> Zwłaszcza chodzi mi o to zdanie: "To taki dość ograniczony i
>>>>> funkcjonalnie i wydajnościowo dodatek."
>>>>> Naprawdę ZEOS jest ograniczonym dodatkiem do MSSQL'a czy obsługa
>>>>> MSSQLa
>>>>> jest ograniczona (funkcjonalnie i wydajnościowo) w ZEOS?
>>>>> A moż to po prostu sarkazm jest? :-)
>>>>
>>>> Zupełnie coś innego. Mówię o połączeniu przez ADO w ZEOS-ie.
>>> No OK, ale OP pytał o coś zupełnie innego...
>>> Nie o ADO w zEOS tylko o porównanie ZEOS vs ADO - a przynajmniej ja to
>>> tak zrozumiałem...
>>
>> Pytał o porównanie dbGo i ZEOS.
> OK.
> Powiedz czego nie rozumiesz co tu napisano?
> Wg Ciebie dbGo to nie ejst ADO??

Pytał o porównanie dotychczas używanego do łączenia z M$SQL dbGo z jak 
rozumiem analogicznym rozwiązaniem do łączenia ZEOS-a z M$SQL. Czyli 
przez ADO w ZEOS-ie.
Powiedz czego ty z kolei nie rozumiesz?
Może narysuje Ci to?:
DELPHI - dbGO(ADO) == DELPHI - ZEOS(ADO)

Clou pytania: "Czy warto użyć tej biblioteki do łączenia się z MsSQL.
Dotychczas używam dbGo i lepiej lub gorzej jednak działają."
Clou odpowiedzi: Nie nie warto. ZEOS-przez ADO robi to gorzej niż DELPHI 
z dbGO(przez ADO jak dla Ciebie, chociaż dotychczas myślałem że jest to 
dla Ciebie oczywiste)

miab

W dniu 2014-05-16 17:03, miab pisze:
> W dniu 2014-05-16 15:13, wloochacz pisze:
>> W dniu 2014-05-16 13:52, miab pisze:
>>> W dniu 2014-05-16 13:24, wloochacz pisze:
>>>> W dniu 2014-05-15 16:03, miab pisze:
>>>>> W dniu 2014-05-15 15:58, wloochacz pisze:
>>>>>> W dniu 2014-05-15 15:47, miab pisze:
>>>>>>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>>>>>>> Witam
>>>>>>>>
>>>>>>>> Z racji tego, że na grupie udziela się aktywnie developer ZEOS-a :)
>>>>>>>> mam
>>>>>>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>>>>>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>>>>>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>>>>>>
>>>>>>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>>>>>>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>>>>>>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>>>>>>> lub Lazarus(owców).
>>>>>> Ale Ty tak poważnie? ;-)
>>>>>> Zwłaszcza chodzi mi o to zdanie: "To taki dość ograniczony i
>>>>>> funkcjonalnie i wydajnościowo dodatek."
>>>>>> Naprawdę ZEOS jest ograniczonym dodatkiem do MSSQL'a czy obsługa
>>>>>> MSSQLa
>>>>>> jest ograniczona (funkcjonalnie i wydajnościowo) w ZEOS?
>>>>>> A moż to po prostu sarkazm jest? :-)
>>>>>
>>>>> Zupełnie coś innego. Mówię o połączeniu przez ADO w ZEOS-ie.
>>>> No OK, ale OP pytał o coś zupełnie innego...
>>>> Nie o ADO w zEOS tylko o porównanie ZEOS vs ADO - a przynajmniej ja to
>>>> tak zrozumiałem...
>>>
>>> Pytał o porównanie dbGo i ZEOS.
>> OK.
>> Powiedz czego nie rozumiesz co tu napisano?
>> Wg Ciebie dbGo to nie ejst ADO??
>
> Pytał o porównanie dotychczas używanego do łączenia z M$SQL dbGo z jak
> rozumiem analogicznym rozwiązaniem do łączenia ZEOS-a z M$SQL. Czyli
> przez ADO w ZEOS-ie.
> Powiedz czego ty z kolei nie rozumiesz?
> Może narysuje Ci to?:
> DELPHI - dbGO(ADO) == DELPHI - ZEOS(ADO)
Nie rozumiem tego, że zafiksowałeś się na ZEOSie...
Ja rozumiem pytanie tak:
Delphi-dbGo-MSSQL vs Delphi-ZEOS-MSSQL
I o to pytał OP, co sam potwierdził.

> Clou pytania: "Czy warto użyć tej biblioteki do łączenia się z MsSQL.
> Dotychczas używam dbGo i lepiej lub gorzej jednak działają."
> Clou odpowiedzi: Nie nie warto. ZEOS-przez ADO robi to gorzej niż DELPHI
> z dbGO(przez ADO jak dla Ciebie, chociaż dotychczas myślałem że jest to
> dla Ciebie oczywiste)
Ja o chlebie, a Ty o niebie...

-- 
wloochacz

W dniu 2014-05-16 18:15, wloochacz pisze:
> W dniu 2014-05-16 17:03, miab pisze:
>> W dniu 2014-05-16 15:13, wloochacz pisze:
>>> W dniu 2014-05-16 13:52, miab pisze:
>>>> W dniu 2014-05-16 13:24, wloochacz pisze:
>>>>> W dniu 2014-05-15 16:03, miab pisze:
>>>>>> W dniu 2014-05-15 15:58, wloochacz pisze:
>>>>>>> W dniu 2014-05-15 15:47, miab pisze:
>>>>>>>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>>>>>>>> Witam
>>>>>>>>>
>>>>>>>>> Z racji tego, że na grupie udziela się aktywnie developer
>>>>>>>>> ZEOS-a :)
>>>>>>>>> mam
>>>>>>>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>>>>>>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>>>>>>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>>>>>>>
>>>>>>>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>>>>>>>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>>>>>>>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>>>>>>>> lub Lazarus(owców).
>>>>>>> Ale Ty tak poważnie? ;-)
>>>>>>> Zwłaszcza chodzi mi o to zdanie: "To taki dość ograniczony i
>>>>>>> funkcjonalnie i wydajnościowo dodatek."
>>>>>>> Naprawdę ZEOS jest ograniczonym dodatkiem do MSSQL'a czy obsługa
>>>>>>> MSSQLa
>>>>>>> jest ograniczona (funkcjonalnie i wydajnościowo) w ZEOS?
>>>>>>> A moż to po prostu sarkazm jest? :-)
>>>>>>
>>>>>> Zupełnie coś innego. Mówię o połączeniu przez ADO w ZEOS-ie.
>>>>> No OK, ale OP pytał o coś zupełnie innego...
>>>>> Nie o ADO w zEOS tylko o porównanie ZEOS vs ADO - a przynajmniej ja to
>>>>> tak zrozumiałem...
>>>>
>>>> Pytał o porównanie dbGo i ZEOS.
>>> OK.
>>> Powiedz czego nie rozumiesz co tu napisano?
>>> Wg Ciebie dbGo to nie ejst ADO??
>>
>> Pytał o porównanie dotychczas używanego do łączenia z M$SQL dbGo z jak
>> rozumiem analogicznym rozwiązaniem do łączenia ZEOS-a z M$SQL. Czyli
>> przez ADO w ZEOS-ie.
>> Powiedz czego ty z kolei nie rozumiesz?
>> Może narysuje Ci to?:
>> DELPHI - dbGO(ADO) == DELPHI - ZEOS(ADO)
> Nie rozumiem tego, że zafiksowałeś się na ZEOSie...
> Ja rozumiem pytanie tak:
> Delphi-dbGo-MSSQL vs Delphi-ZEOS-MSSQL
> I o to pytał OP, co sam potwierdził.

No widzisz nie znasz(cie) ZEOS-a:
Delphi - ZEOS- M$SQL to jest:
DELPHI - ZEOS(ADO) - M$SQL i
lub DELPHI - ZEOS(FreeTDS) - M$SQL
Oba rozwiązania niedoskonałe to pierwsze ustępuje dbGO to drugie zbyt 
efemeryczne. Oba zadowalające w przypadku importu danych od M$.
Na marginesie popełniłem aplikacje produkcyjna, która działa z FreeTDS 
ale robi on tylko w zasadzie jedno, importuje (dość trywialne) dane z 
M$SQL-a po to by po letkim przetworzeniu wysłać je na MySQL na 
webserwerze(i potrzebuje do tego siebie samej i dwu bibliotek klienckich 
freetds-owej i mysql-owej).
Tak że spokojnie może być 32 i 64-bitowa Windziana jak i Linux-owa.
I tak widzę rozsądne użycie ZEOS-a w  przypadku M$SQL-a.
Po prostu do wyrafinowanego użycia M$SQL-a w DELPHI są lepsze biblioteki.

miab

W dniu 16.05.2014 18:55, miab3 pisze:
> W dniu 2014-05-16 18:15, wloochacz pisze:
>> W dniu 2014-05-16 17:03, miab pisze:
>>> W dniu 2014-05-16 15:13, wloochacz pisze:
>>>> W dniu 2014-05-16 13:52, miab pisze:
>>>>> W dniu 2014-05-16 13:24, wloochacz pisze:
>>>>>> W dniu 2014-05-15 16:03, miab pisze:
>>>>>>> W dniu 2014-05-15 15:58, wloochacz pisze:
>>>>>>>> W dniu 2014-05-15 15:47, miab pisze:
>>>>>>>>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>>>>>>>>> Witam
>>>>>>>>>>
>>>>>>>>>> Z racji tego, że na grupie udziela się aktywnie developer
>>>>>>>>>> ZEOS-a :)
>>>>>>>>>> mam
>>>>>>>>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>>>>>>>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>>>>>>>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>>>>>>>>
>>>>>>>>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>>>>>>>>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>>>>>>>>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>>>>>>>>> lub Lazarus(owców).
>>>>>>>> Ale Ty tak poważnie? ;-)
>>>>>>>> Zwłaszcza chodzi mi o to zdanie: "To taki dość ograniczony i
>>>>>>>> funkcjonalnie i wydajnościowo dodatek."
>>>>>>>> Naprawdę ZEOS jest ograniczonym dodatkiem do MSSQL'a czy obsługa
>>>>>>>> MSSQLa
>>>>>>>> jest ograniczona (funkcjonalnie i wydajnościowo) w ZEOS?
>>>>>>>> A moż to po prostu sarkazm jest? :-)
>>>>>>>
>>>>>>> Zupełnie coś innego. Mówię o połączeniu przez ADO w ZEOS-ie.
>>>>>> No OK, ale OP pytał o coś zupełnie innego...
>>>>>> Nie o ADO w zEOS tylko o porównanie ZEOS vs ADO - a przynajmniej
>>>>>> ja to
>>>>>> tak zrozumiałem...
>>>>>
>>>>> Pytał o porównanie dbGo i ZEOS.
>>>> OK.
>>>> Powiedz czego nie rozumiesz co tu napisano?
>>>> Wg Ciebie dbGo to nie ejst ADO??
>>>
>>> Pytał o porównanie dotychczas używanego do łączenia z M$SQL dbGo z jak
>>> rozumiem analogicznym rozwiązaniem do łączenia ZEOS-a z M$SQL. Czyli
>>> przez ADO w ZEOS-ie.
>>> Powiedz czego ty z kolei nie rozumiesz?
>>> Może narysuje Ci to?:
>>> DELPHI - dbGO(ADO) == DELPHI - ZEOS(ADO)
>> Nie rozumiem tego, że zafiksowałeś się na ZEOSie...
>> Ja rozumiem pytanie tak:
>> Delphi-dbGo-MSSQL vs Delphi-ZEOS-MSSQL
>> I o to pytał OP, co sam potwierdził.
>
> No widzisz nie znasz(cie) ZEOS-a:
> Delphi - ZEOS- M$SQL to jest:
> DELPHI - ZEOS(ADO) - M$SQL i
> lub DELPHI - ZEOS(FreeTDS) - M$SQL
> Oba rozwiązania niedoskonałe to pierwsze ustępuje dbGO to drugie zbyt
> efemeryczne. Oba zadowalające w przypadku importu danych od M$.
> Na marginesie popełniłem aplikacje produkcyjna, która działa z FreeTDS
> ale robi on tylko w zasadzie jedno, importuje (dość trywialne) dane z
> M$SQL-a po to by po letkim przetworzeniu wysłać je na MySQL na
> webserwerze(i potrzebuje do tego siebie samej i dwu bibliotek klienckich
> freetds-owej i mysql-owej).
> Tak że spokojnie może być 32 i 64-bitowa Windziana jak i Linux-owa.
> I tak widzę rozsądne użycie ZEOS-a w  przypadku M$SQL-a.
> Po prostu do wyrafinowanego użycia M$SQL-a w DELPHI są lepsze biblioteki.
>
> miab
>
>

Czyli mam rozumieć że jeśli wybiore w zConnection M$SSQL to i tak poleci 
przez ADO? jeśli tak to szkoda :(

Pozdrawiam

W dniu 2014-05-16 19:06, J-23 pisze:
> W dniu 16.05.2014 18:55, miab3 pisze:
>> W dniu 2014-05-16 18:15, wloochacz pisze:
>>> W dniu 2014-05-16 17:03, miab pisze:
>>>> W dniu 2014-05-16 15:13, wloochacz pisze:
>>>>> W dniu 2014-05-16 13:52, miab pisze:
>>>>>> W dniu 2014-05-16 13:24, wloochacz pisze:
>>>>>>> W dniu 2014-05-15 16:03, miab pisze:
>>>>>>>> W dniu 2014-05-15 15:58, wloochacz pisze:
>>>>>>>>> W dniu 2014-05-15 15:47, miab pisze:
>>>>>>>>>> W dniu 2014-05-15 15:00, pbk++ pisze:
>>>>>>>>>>> Witam
>>>>>>>>>>>
>>>>>>>>>>> Z racji tego, że na grupie udziela się aktywnie developer
>>>>>>>>>>> ZEOS-a :)
>>>>>>>>>>> mam
>>>>>>>>>>> pytanie. Czy warto użyć tej biblioteki do łączenia się z MsSQL?
>>>>>>>>>>> Dotychczas używam dbGo i lepiej lub gorzej jednak działają.
>>>>>>>>>>> Czy ZEOS ma jakąś przewagę nad dbGo?
>>>>>>>>>>
>>>>>>>>>> Nie. W tym przypadku ZEOS nie ma żadnych przewag.
>>>>>>>>>> To taki dość ograniczony i funkcjonalnie i wydajnościowo dodatek.
>>>>>>>>>> Raczej dla tych którzy epizodycznie chcieli by skorzystać z niego
>>>>>>>>>> lub Lazarus(owców).
>>>>>>>>> Ale Ty tak poważnie? ;-)
>>>>>>>>> Zwłaszcza chodzi mi o to zdanie: "To taki dość ograniczony i
>>>>>>>>> funkcjonalnie i wydajnościowo dodatek."
>>>>>>>>> Naprawdę ZEOS jest ograniczonym dodatkiem do MSSQL'a czy obsługa
>>>>>>>>> MSSQLa
>>>>>>>>> jest ograniczona (funkcjonalnie i wydajnościowo) w ZEOS?
>>>>>>>>> A moż to po prostu sarkazm jest? :-)
>>>>>>>>
>>>>>>>> Zupełnie coś innego. Mówię o połączeniu przez ADO w ZEOS-ie.
>>>>>>> No OK, ale OP pytał o coś zupełnie innego...
>>>>>>> Nie o ADO w zEOS tylko o porównanie ZEOS vs ADO - a przynajmniej
>>>>>>> ja to
>>>>>>> tak zrozumiałem...
>>>>>>
>>>>>> Pytał o porównanie dbGo i ZEOS.
>>>>> OK.
>>>>> Powiedz czego nie rozumiesz co tu napisano?
>>>>> Wg Ciebie dbGo to nie ejst ADO??
>>>>
>>>> Pytał o porównanie dotychczas używanego do łączenia z M$SQL dbGo z jak
>>>> rozumiem analogicznym rozwiązaniem do łączenia ZEOS-a z M$SQL. Czyli
>>>> przez ADO w ZEOS-ie.
>>>> Powiedz czego ty z kolei nie rozumiesz?
>>>> Może narysuje Ci to?:
>>>> DELPHI - dbGO(ADO) == DELPHI - ZEOS(ADO)
>>> Nie rozumiem tego, że zafiksowałeś się na ZEOSie...
>>> Ja rozumiem pytanie tak:
>>> Delphi-dbGo-MSSQL vs Delphi-ZEOS-MSSQL
>>> I o to pytał OP, co sam potwierdził.
>>
>> No widzisz nie znasz(cie) ZEOS-a:
>> Delphi - ZEOS- M$SQL to jest:
>> DELPHI - ZEOS(ADO) - M$SQL i
>> lub DELPHI - ZEOS(FreeTDS) - M$SQL
>> Oba rozwiązania niedoskonałe to pierwsze ustępuje dbGO to drugie zbyt
>> efemeryczne. Oba zadowalające w przypadku importu danych od M$.
>> Na marginesie popełniłem aplikacje produkcyjna, która działa z FreeTDS
>> ale robi on tylko w zasadzie jedno, importuje (dość trywialne) dane z
>> M$SQL-a po to by po letkim przetworzeniu wysłać je na MySQL na
>> webserwerze(i potrzebuje do tego siebie samej i dwu bibliotek klienckich
>> freetds-owej i mysql-owej).
>> Tak że spokojnie może być 32 i 64-bitowa Windziana jak i Linux-owa.
>> I tak widzę rozsądne użycie ZEOS-a w  przypadku M$SQL-a.
>> Po prostu do wyrafinowanego użycia M$SQL-a w DELPHI są lepsze biblioteki.
>>
>> miab
>>
>>
>
> Czyli mam rozumieć że jeśli wybiore w zConnection M$SSQL to i tak poleci
> przez ADO? jeśli tak to szkoda :(

Nie całkiem. W ZEOS-ie są dwa(a właściwie trzy kanały) do M$SQL.
Protocol:
ado(które należy skonfigurować tak jak się konfiguruje ADO z wachlarzem 
jego możliwości i opcji w connection string),
FreeTDS,
i mssql(i tu jest używany prehistoryczny majkrosofciany ntwdblib.dll 
protoplasta FreeTDS-a, o którym przezornie nie wspomniałem bo to jak 
powiedziałem windziana nieaktualizowana i zamknięta od lat 32-bitowa 
prehistoria).

miab

W dniu 2014-05-16 13:32, pbk++ pisze:
> W dniu 2014-05-15 20:37, Krzysztof Szyszka pisze:
>>> > Jak jest ze wsparciem dla C++ Builder-a?
>>>
>>> W RAD STUDIO można utworzyć biblioteki do C++ i pisać w nim(testowałem).
>>> Z tego wynika że istnieje możliwość zainstalowania go do samodzielnego
>>> BCB tylko trzeba popełnić zestaw stosownych pakietów instalacyjnych(w
>>> czym nie mam doświadczenia). Można się pewnie posiłkować przykładowym
>>> pakietem cbuilder12.
>>
>> Jak masz pakiety *.dpk utworzone w Delphi, to dla C++Buildera nie trzeba
>> nic nowego tworzyć.
>> Wystarczy przekompilować te pakiety z dodatkowymi przełącznikami, żeby
>> utworzyły się pliki
>> *.hpp i *.bpi. Plik *.bpl jest wtedy wspólny dla Delphi i C++Buildera.
>>
>
>
> To to ja wiem. Siedzę w BCB od nastu lat. Tyle, że podjąłem próbę
> instalacji i jak na razie porażka, tj. wszystko się kompiluje, generuje
> header-y i obiekty dla BCB, komponenty są widoczne w Delphi, ale BCB już
> nie. Tj. pakiet jest niby zainstalowany, ale nie widać go na palecie
> komponentów.
>
> Będę próbował raz jeszcze w wolnej chwili.
>
> BCB 2010 Pro

Skoro C++ Ci nie obcy :) to może byś skompilował w miarę aktualną 
bibliotekę FreeTDS do 32-bitowego (i jak możesz 64-bitowego) windzianego 
dll-a i wrzucił gdzieś do pobrania.
Źródełka znajdziesz na końcu listy:
ftp://ftp.freetds.org/pub/freetds/current/
Coś np. w rodzaju:
freetds-dev.0.92.705.tar.bz2
czy
freetds-dev.0.92.705.tar.gz

miab

W dniu 2014-05-16 18:55, miab3 pisze:
/ciach/

>>> Pytał o porównanie dotychczas używanego do łączenia z M$SQL dbGo z jak
>>> rozumiem analogicznym rozwiązaniem do łączenia ZEOS-a z M$SQL. Czyli
>>> przez ADO w ZEOS-ie.
>>> Powiedz czego ty z kolei nie rozumiesz?
>>> Może narysuje Ci to?:
>>> DELPHI - dbGO(ADO) == DELPHI - ZEOS(ADO)
>> Nie rozumiem tego, że zafiksowałeś się na ZEOSie...
>> Ja rozumiem pytanie tak:
>> Delphi-dbGo-MSSQL vs Delphi-ZEOS-MSSQL
>> I o to pytał OP, co sam potwierdził.
>
> No widzisz nie znasz(cie) ZEOS-a:
> Delphi - ZEOS- M$SQL to jest:
> DELPHI - ZEOS(ADO) - M$SQL i
> lub DELPHI - ZEOS(FreeTDS) - M$SQL
Prawda, nie znam się. Jednakże to co napisałeś sugerowało raczej, że 
istnieje takie rozwiazanie w ZEOS, które potrafi działać z dowolną bazą 
danych przez ADO - w tym i do MSSQL.
Nie wpadłbym na to, że to "działa" tak jak opisujesz..
Wszystko jeszcze zalezy od tego jak ZEOS rozmawia z ADO. Jeśli używa 
natywnych interfejsów (bez opakowania z dbGO a tym bardziej z 
pominięciem ADODataSet) to nie powinno być źle.
Jeśli jest inaczej - to jest... ;-)

> Oba rozwiązania niedoskonałe to pierwsze ustępuje dbGO to drugie zbyt
> efemeryczne. Oba zadowalające w przypadku importu danych od M$.
> Na marginesie popełniłem aplikacje produkcyjna, która działa z FreeTDS
> ale robi on tylko w zasadzie jedno, importuje (dość trywialne) dane z
> M$SQL-a po to by po letkim przetworzeniu wysłać je na MySQL na
> webserwerze(i potrzebuje do tego siebie samej i dwu bibliotek klienckich
> freetds-owej i mysql-owej).
> Tak że spokojnie może być 32 i 64-bitowa Windziana jak i Linux-owa.
> I tak widzę rozsądne użycie ZEOS-a w  przypadku M$SQL-a.
> Po prostu do wyrafinowanego użycia M$SQL-a w DELPHI są lepsze biblioteki.
Wyrafinowanego? A co w tym wyrafinowanego?
Nie bawmy się w ozdobniki - to jest po prostu kupa i tyle, która jak sam 
powiedziałeś, nadaje się do incydentalnego dostępu do MSSQL, a nie do 
normalnej pracy.
Tyle dobrze, że już się wyjaśniło o co w tym wszystkim chodzi.
A tak w ogóle w planach jest wymiana tego na coś bardziej "normalnego"?

-- 
wloochacz

W dniu 2014-05-16 22:04, wloochacz pisze:
(...)
>> I tak widzę rozsądne użycie ZEOS-a w  przypadku M$SQL-a.
>> Po prostu do wyrafinowanego użycia M$SQL-a w DELPHI są lepsze biblioteki.
> Wyrafinowanego? A co w tym wyrafinowanego?
> Nie bawmy się w ozdobniki - to jest po prostu kupa i tyle, która jak sam
> powiedziałeś, nadaje się do incydentalnego dostępu do MSSQL, a nie do
> normalnej pracy.

I o takie podsumowanie chodziło.

Sprawa jest jasna. Pozostaję na BCB2010 więc nie ma sensu przechodzić na 
nic innego niż dbGo. Raz umiem, dwa szkoda pieniędzy na inne rozwiązania.

Dziękuję wszystkim za uwagi.
--
Piotrek

W dniu 2014-05-17 10:14, pbk++ pisze:
> W dniu 2014-05-16 22:04, wloochacz pisze:
> (...)
>>> I tak widzę rozsądne użycie ZEOS-a w  przypadku M$SQL-a.
>>> Po prostu do wyrafinowanego użycia M$SQL-a w DELPHI są lepsze
>>> biblioteki.
>> Wyrafinowanego? A co w tym wyrafinowanego?
>> Nie bawmy się w ozdobniki - to jest po prostu kupa i tyle, która jak sam
>> powiedziałeś, nadaje się do incydentalnego dostępu do MSSQL, a nie do
>> normalnej pracy.
>
> I o takie podsumowanie chodziło.
>
> Sprawa jest jasna. Pozostaję na BCB2010 więc nie ma sensu przechodzić na
> nic innego niż dbGo. Raz umiem, dwa szkoda pieniędzy na inne rozwiązania.
>

A tak na marginesie.
W przypadku MySQL/MariaDB, PostgreSQL, Firebird/Interbase i Oracle ZEOS- 
jest dobrą alternatywą (do tego darmową).
A już szczególnie dobrą jest w przypadku perspektyw konieczności 
kompilacji na Linux-a i pokrewne czy/i użycia Lazarusa ewentualnie 
aplikacji z wymaganym dostępem do wielu różnych serwerów db.
Tak jak pisałem M$ jest traktowany w ZEOS-ie trochę po macoszemu bo to 
trochę inny target (powiedzmy tych którzy nie przepadają za, czy też nie 
muszą używać baz M$'a).

miab

W dniu 2014-05-17 11:20, miab pisze:
> W dniu 2014-05-17 10:14, pbk++ pisze:
>> W dniu 2014-05-16 22:04, wloochacz pisze:
>> (...)
>>>> I tak widzę rozsądne użycie ZEOS-a w  przypadku M$SQL-a.
>>>> Po prostu do wyrafinowanego użycia M$SQL-a w DELPHI są lepsze
>>>> biblioteki.
>>> Wyrafinowanego? A co w tym wyrafinowanego?
>>> Nie bawmy się w ozdobniki - to jest po prostu kupa i tyle, która jak sam
>>> powiedziałeś, nadaje się do incydentalnego dostępu do MSSQL, a nie do
>>> normalnej pracy.
>>
>> I o takie podsumowanie chodziło.
>>
>> Sprawa jest jasna. Pozostaję na BCB2010 więc nie ma sensu przechodzić na
>> nic innego niż dbGo. Raz umiem, dwa szkoda pieniędzy na inne rozwiązania.
>>
>
> A tak na marginesie.
> W przypadku MySQL/MariaDB, PostgreSQL, Firebird/Interbase i Oracle ZEOS-
> jest dobrą alternatywą (do tego darmową).
> A już szczególnie dobrą jest w przypadku perspektyw konieczności
> kompilacji na Linux-a i pokrewne czy/i użycia Lazarusa ewentualnie
> aplikacji z wymaganym dostępem do wielu różnych serwerów db.
> Tak jak pisałem M$ jest traktowany w ZEOS-ie trochę po macoszemu bo to
> trochę inny target (powiedzmy tych którzy nie przepadają za, czy też nie
> muszą używać baz M$'a).
Moim zdaniem, to niepoważne podejście. Prawda jest taka, że MSSQL jest 
bardzo popularną (może nawet najpopularniejszą w tej chwili) bazą danych 
na platformie Windows, zwłaszcza dla małych i średnich potrzeb.

-- 
wloochacz

W dniu 2014-05-17 14:40, wloochacz pisze:
> W dniu 2014-05-17 11:20, miab pisze:
>> W dniu 2014-05-17 10:14, pbk++ pisze:
>>> W dniu 2014-05-16 22:04, wloochacz pisze:
>>> (...)
>>>>> I tak widzę rozsądne użycie ZEOS-a w  przypadku M$SQL-a.
>>>>> Po prostu do wyrafinowanego użycia M$SQL-a w DELPHI są lepsze
>>>>> biblioteki.
>>>> Wyrafinowanego? A co w tym wyrafinowanego?
>>>> Nie bawmy się w ozdobniki - to jest po prostu kupa i tyle, która jak
>>>> sam
>>>> powiedziałeś, nadaje się do incydentalnego dostępu do MSSQL, a nie do
>>>> normalnej pracy.
>>>
>>> I o takie podsumowanie chodziło.
>>>
>>> Sprawa jest jasna. Pozostaję na BCB2010 więc nie ma sensu przechodzić na
>>> nic innego niż dbGo. Raz umiem, dwa szkoda pieniędzy na inne
>>> rozwiązania.
>>>
>>
>> A tak na marginesie.
>> W przypadku MySQL/MariaDB, PostgreSQL, Firebird/Interbase i Oracle ZEOS-
>> jest dobrą alternatywą (do tego darmową).
>> A już szczególnie dobrą jest w przypadku perspektyw konieczności
>> kompilacji na Linux-a i pokrewne czy/i użycia Lazarusa ewentualnie
>> aplikacji z wymaganym dostępem do wielu różnych serwerów db.
>> Tak jak pisałem M$ jest traktowany w ZEOS-ie trochę po macoszemu bo to
>> trochę inny target (powiedzmy tych którzy nie przepadają za, czy też nie
>> muszą używać baz M$'a).
> Moim zdaniem, to niepoważne podejście. Prawda jest taka, że MSSQL jest
> bardzo popularną (może nawet najpopularniejszą w tej chwili) bazą danych
> na platformie Windows, zwłaszcza dla małych i średnich potrzeb.

Ale jest pare aspektów.
Po pierwsze M$SQL jest zamkniety.
Po drugie prawie co sezon M$ zmienia koncepcje jak powinno sie do niego 
łączyć i zaczyna lansować kolejny zestaw zamkniętych rozwiązań
Po trzecie jest spore obibilotekowanie do niego i od M$-a i od trzecich.
Po czwarte ZEOS jak najbardziej współpracuje z M$SQL-em, a nawet więcęj 
z wszystkim co da się przepuścic przez ADO.
A po piąte używa też i rozwija porzucone przez M$-a rozwiązanie(na 
marginesie FreeTDS używany jest w np. PHP do tego samego).
Na drugim marginesie przez FreeTDS można się też łączyć do SYBASE (co 
wynika z tego że M$SQL był po prostu onegdaj kupiony od SYBASE).
Chyba wystarczająco dużo tego robienia na rękę M$-owi.

miab