Tomasz Chudobiecki

Tomasz Chudobiecki Programista,
projektant

Temat: Kilka pytań o AnyDAC/FireDAC

Witam
Mam kilka pytań związanych z AnyDAC/FireDAC.
Jeżeli dobrze rozumiem to FireDAC zastępuje AnyDAC?
Aktualnie pracuję w Delphi 2009. Aplikacja oparta o IBX i Firebirda. I pojawił się pomysł, żeby może zmienić bazę na MSSQL.
Teraz pytania. Czy FireDAC zadziała mi na Delphi 2009? Jak jest z trudnością zmiany komponentów z IBX na FireDAC (same komponenty w aplikacji, baza to wiem, że odrębna sprawa)? Jeżeli już przejdę na FireDAC to czy bardzo kłopotliwe jest utrzymywanie możliwości korzystania z dwóch (lub więcej) silników baz (Firebrid i MSSQL).
Z góry dziękuje za odpowiedzi.
Daniel Grabowski

Daniel Grabowski Interaktywne
planowanie produkcji
on-line z MES

Temat: Kilka pytań o AnyDAC/FireDAC

Tomasz Chudobiecki:
Witam
Mam kilka pytań związanych z AnyDAC/FireDAC.
Jeżeli dobrze rozumiem to FireDAC zastępuje AnyDAC?
Tak, to jest dokładnie to samo.
Sam autor sprzedał firmę i teraz pracuję w Emba jak FireDAC Architect.
Aktualnie pracuję w Delphi 2009. Aplikacja oparta o IBX i Firebirda. I pojawił się pomysł, żeby może zmienić bazę na MSSQL.
Pomysł może i dobry, ale to zależy co to za aplikacja i dlaczego chcecie przenieść się na MS SQL'a?
No offence, sam pisałem małe rzeczy na FB, ale potem zacząłem pisać większe rzeczy w oparciu o MSSQL i tak już zostało...
Tak czy siak, osobiście uważam FB za bardzo dobrą bazę danych - do typowych aplikacji OLTP.
MSSQL też jest bardzo dobry, ale pewne rzeczy robi się zdecydowanie inaczej.
Teraz pytania. Czy FireDAC zadziała mi na Delphi 2009?
Zadziała;
Tu więcej na ten temat:
https://forums.embarcadero.com/thread.jspa?threadID=841...
A jak Ci się nie uda, do daj znać - dam Ci paczki i grupę projektów dla D2009 i skompilujesz sobie ręcznie.
Jak jest z trudnością zmiany komponentów z IBX na FireDAC (same komponenty w aplikacji, baza to wiem, że odrębna sprawa)?
Na to pytanie ciężko odpowiedzieć, bo wszystko zależy jak to zrealizowałeś za pomocą DBX.
Ale co ciekawe, nie ma absolutnie potrzeby używania Client DataSet'a. Wszystko to co jest w CDS (i zdecydowanie więcej) jest już w komponencie TADQuery. Po prostu.
Także FireDAC jest po pierwsze prostszy a po drugie zdecydowanie bardziej elastyczny od DBX'a.
Łatwiejszy jest też deploment aplikacji, bo nie musisz z nią dystrybuować żadnych sterowników dedykowanych do bazy danych, jak w przypadku DBX.
Jeżeli już przejdę na FireDAC to czy bardzo kłopotliwe jest utrzymywanie możliwości korzystania z dwóch (lub więcej) silników baz (Firebrid i MSSQL).
I tak i nie; naprawdę wszystko zależy w jakim stopniu Twoja aplikacja operuje SQL'em.
Ale zapewniam Cię, że w FireDAC da się zrobić wszystko.
Stosunkowo proste i typowe zagadnienia (czyli dowolne polecania DML czy wykonywanie procedur) są realizowane od ręki. Naprawdę fikuśne i absolutnie typowe dla konkretnej bazy danych, zawsze możesz otoczyć odpowiednią dyrektywą w zapytaniu SQL; tu więcej an ten temat:
http://docs.embarcadero.com/products/rad_studio/fireda...
Tomasz Chudobiecki

Tomasz Chudobiecki Programista,
projektant

Temat: Kilka pytań o AnyDAC/FireDAC

Dzięki za odpowiedź.
Głównym powodem prób przejścia na MSSQL jest to, że nie tylko aplikacja w Delphi korzysta z tej bazy. I w niektórych przypadkach po prostu dużo łatwiej jest dostać się do MSSQL niż do Firebirda (nie ma łatwej możliwości dostania się do FB jedynie przez webservice co znacznie komplikuje).

Aktualnie korzystamy z IBX nie DBX. Generalnie wykorzystujemy coś własnego co opakowuje TIBQuery i TIBUpdateSQL.
Daniel Grabowski

Daniel Grabowski Interaktywne
planowanie produkcji
on-line z MES

Temat: Kilka pytań o AnyDAC/FireDAC

Tomasz Chudobiecki:
Dzięki za odpowiedź.
Głównym powodem prób przejścia na MSSQL jest to, że nie tylko aplikacja w Delphi korzysta z tej bazy. I w niektórych przypadkach po prostu dużo łatwiej jest dostać się do MSSQL niż do Firebirda (nie ma łatwej możliwości dostania się do FB jedynie przez webservice co znacznie komplikuje).
Dla mnie ta argumenty nie są jasne...
Co to znaczy, że "nie ma łatwej możliwości dostania się do FB jedynie przez webservice co znacznie komplikuje"?
To jest maslo maślane - co ma WS do bazy danych?
Nic. I wszystko.
A dostać się do FB można łątwo z wielu języków programowania; do Delphi jest mnóstwo natywnych rozwiązań. Do .NET masz dedykowany Data Provider, do Javy jest sterownik JDBC, jest oczywiście sterownik ODBC i provider OLEDB - zresztą, co ja się będę produkował:
http://www.firebirdsql.org/en/development/
Aktualnie korzystamy z IBX nie DBX.
To jeszcze upraszcza sprawę i daje Wam ogromne pole do popisu, czego w IBX próżno szukać.
Generalnie wykorzystujemy coś własnego co opakowuje TIBQuery i TIBUpdateSQL.
A to ciekawe, możesz napisać więcej o tym wrapperze?
Co on takiego robi i po co?

PS.
TIBQuery i TIBUpdateSQL to przecież TIBDataset, ale to pewnie wiecie ;-)
Tomasz Chudobiecki

Tomasz Chudobiecki Programista,
projektant

Temat: Kilka pytań o AnyDAC/FireDAC

Daniel Grabowski:

Dla mnie ta argumenty nie są jasne...
Co to znaczy, że "nie ma łatwej możliwości dostania się do FB jedynie przez webservice co znacznie komplikuje"?
To jest maslo maślane - co ma WS do bazy danych?
Chcemy się dostać z SharePoint do bazy danych Firebird i nie jest to łatwe w sposób bezpośredni. Dlatego rozważamy możliwość zmiany bazy na MSSQL.
A to ciekawe, możesz napisać więcej o tym wrapperze?
Co on takiego robi i po co?

PS.
TIBQuery i TIBUpdateSQL to przecież TIBDataset, ale to pewnie wiecie ;-)
Ogólnie robi to samo co TIBDataSet. A dlaczego powstał to nie wiem, bo powstał już jakiś czas temu.
Jacek Gaża

Jacek Gaża IT Manager, Tamtron
S.A.

Temat: Kilka pytań o AnyDAC/FireDAC

Tomasz zastanów się jeszcze nad UNIDAC, produkt DEVART - rzuć sobie okiem :
http://www.devart.com/unidac/
Niedrogi i bardzo dobry support.
Nie wiem jak cenowo wychodzi FireDAC ale komponenty UNIDAC są w naprawdę korzystnej cenie.
Pozdrawiam
Jacek
ps. Nie pracuję dla DevArt :)
Przemysław Osmański

Przemysław Osmański projektant / opiekun
produktu /
programista

Temat: Kilka pytań o AnyDAC/FireDAC

Tak, dodatkowo DevArt ma tę zaletę, że jest niezależy od Emb. A co za tym idzie, można zainstalować najnowszą wersję na dowolnym wspieranym Delphi. Z FireDAC'em jest tak, że nowy FireDAC = nowe Delphi. Za drogo i bez sensu jeśli upgradeować się tylko dla FD.
Piotr Deska

Piotr Deska Software Development
Engineer SOFT-ART

Temat: Kilka pytań o AnyDAC/FireDAC

Jacek G.:
Tomasz zastanów się jeszcze nad UNIDAC, produkt DEVART - rzuć sobie okiem :
http://www.devart.com/unidac/
Niedrogi i bardzo dobry support.
Nie wiem jak cenowo wychodzi FireDAC ale komponenty UNIDAC są w naprawdę korzystnej cenie.
Pozdrawiam
Jacek
ps. Nie pracuję dla DevArt :)

Popieram w 100% - w ubiegłych latach przeniosłem kilka sporych projektów z Firebird na MSSQL dla jednej z trójmiejskich firm.
Co ciekawe należało stworzyć rozwiązanie pozwalające na korzystanie zamiennie z MS SQL lub Firebird w zależności od tego co ustawił sobie user w konfiguracji. Ponieważ systemy te "pracują" w bardzo wielu miejscach od lat i niekoniecznie ludziska chcą zmieniać bazę danych (ciekawe czemu? jakie to ma znaczenia dla usera końcowego?) ;)

I.. wbrew pozorom nie było to "olbrzymie" wyzwanie - przeciętnie miesiąc moje pracy (co prawda po kilkanaście h/dobę).

Trochę "case'ów" należało założyć ale niezbyt wiele a i to raczej tylko w bazowym DM.

Tak czy tak jeśli koniecznie ktoś chce zmieniać bazę to polecam UniDac.

PS.
Oczywiście też nie pracuję dla DevArt :P
Daniel Grabowski

Daniel Grabowski Interaktywne
planowanie produkcji
on-line z MES

Temat: Kilka pytań o AnyDAC/FireDAC

Piotr D.:
Jacek G.:
Tomasz zastanów się jeszcze nad UNIDAC, produkt DEVART - rzuć sobie okiem :
http://www.devart.com/unidac/
Niedrogi i bardzo dobry support.
Nie wiem jak cenowo wychodzi FireDAC ale komponenty UNIDAC są w naprawdę korzystnej cenie.
Pozdrawiam
Jacek
ps. Nie pracuję dla DevArt :)

Popieram w 100% - w ubiegłych latach przeniosłem kilka sporych projektów z Firebird na MSSQL dla jednej z trójmiejskich firm.
Co ciekawe należało stworzyć rozwiązanie pozwalające na korzystanie zamiennie z MS SQL lub Firebird w zależności od tego co ustawił sobie user w konfiguracji. Ponieważ systemy te "pracują" w bardzo wielu miejscach od lat i niekoniecznie ludziska chcą zmieniać bazę danych (ciekawe czemu? jakie to ma znaczenia dla usera końcowego?) ;)
Dla usera - żadnego.
Dla IT, administratora, informatyka w firmie - ogromne.
Dla usera, który nie ma informatyka - ogromne.
I.. wbrew pozorom nie było to "olbrzymie" wyzwanie - przeciętnie miesiąc moje pracy (co prawda po kilkanaście h/dobę).

Trochę "case'ów" należało założyć ale niezbyt wiele a i to raczej tylko w bazowym DM.
Ekhm... a po co te Case'y?
Możesz dać jakiś przykład?
Piotr Deska

Piotr Deska Software Development
Engineer SOFT-ART

Temat: Kilka pytań o AnyDAC/FireDAC

Daniel G.:
Piotr D.:
Jacek G.:
Tomasz zastanów się jeszcze nad UNIDAC, produkt DEVART - rzuć sobie okiem :
http://www.devart.com/unidac/
Niedrogi i bardzo dobry support.
Nie wiem jak cenowo wychodzi FireDAC ale komponenty UNIDAC są w naprawdę korzystnej cenie.
Pozdrawiam
Jacek
ps. Nie pracuję dla DevArt :)

Popieram w 100% - w ubiegłych latach przeniosłem kilka sporych projektów z Firebird na MSSQL dla jednej z trójmiejskich firm.
Co ciekawe należało stworzyć rozwiązanie pozwalające na korzystanie zamiennie z MS SQL lub Firebird w zależności od tego co ustawił sobie user w konfiguracji. Ponieważ systemy te "pracują" w bardzo wielu miejscach od lat i niekoniecznie ludziska chcą zmieniać bazę danych (ciekawe czemu? jakie to ma znaczenia dla usera końcowego?) ;)
Dla usera - żadnego.
Dla IT, administratora, informatyka w firmie - ogromne.
Dla usera, który nie ma informatyka - ogromne.
System powinien być (przynajmniej w teorii ;) ) samoobsługiwalny m.in. w zakresie backup, definiowania raportów etc.
Patrząc z mojego pkt. widzenia jako projektanta/programisty a nie gościa od bieżącego utrzymania nie widzę specjalnych różnic ;)
I.. wbrew pozorom nie było to "olbrzymie" wyzwanie - przeciętnie miesiąc moje pracy (co prawda po kilkanaście h/dobę).

Trochę "case'ów" należało założyć ale niezbyt wiele a i to raczej tylko w bazowym DM.
Ekhm... a po co te Case'y?
Możesz dać jakiś przykład?

Pewnie można to inaczej było rozwiązać ale ponieważ technologia samyc projektów była dośc archaiczna to CASE przydawało się chocby do obsługi SQL "na żywca" przekazywanego - niektóre rzeczy są jednak różne w składni.
Trochę takich dziwnych rzeczy trezba było gdzieś uwzglednić.

Zresztą nie zawsze robi się wszystko zgodnie z najwyższym standardem - jak zawsze sprawy kosztowo/czasowe wymuszają szukanie rozwiazań pośrednich. Nikt nie zapłaci za idealne (czy też zgodne ze wszystkimi kanonami) rozwiazanie, które działa i robi to samo co "łatka" a kosztuje kilka razy wiecej czasu (i kasy ;) ).

pozdrawiam
Piotr



Wyślij zaproszenie do