Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Pomocy - "Połączenie jest zajęte wynikami dla innego hstmt"
561 views
Skip to first unread message
boloc...@gmail.com
Feb 29, 2016, 4:44:25 AM2/29/16
to
Witam wszystkich
Wiem, ze kiedy ten watek byl, ale rozwiazenie tam sugerowane Fetch = fmAll jest obejsciem a nie rozwiazniem. :/
Dlatego ponawiam watek (w pewnym sensie) - czemu w XE3 aplikacja an MSSQL 2005 wywala taki blad!
MARS w ustawieniach FireDAC'a jest wlaczony, nie ma zadnych cudow - ot kilka ADQuery, otwieranych w zaleznosci od potrzeb.
A tnie sie niesamowicie - dodatkowo uruchomienie procedury skladowanej powoduje deadlock!! poziom izoalcji ustawiony jest ReadCommited, tranzakcje sa bardzo krotkie.
Ta sama aplikacja, ale skompilowana w D2007 na AnyDAC'u, z tymi samymi ustawieniami na tym samym serwerze chodzi na 60 stanowiskach bez zajakniecia.
Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL ale czy to jest rozwiaznie?
Jakie podpowiedzi?
Pozdrawiam
Bolo
Wiem, ze kiedy ten watek byl, ale rozwiazenie tam sugerowane Fetch = fmAll jest obejsciem a nie rozwiazniem. :/
Dlatego ponawiam watek (w pewnym sensie) - czemu w XE3 aplikacja an MSSQL 2005 wywala taki blad!
MARS w ustawieniach FireDAC'a jest wlaczony, nie ma zadnych cudow - ot kilka ADQuery, otwieranych w zaleznosci od potrzeb.
A tnie sie niesamowicie - dodatkowo uruchomienie procedury skladowanej powoduje deadlock!! poziom izoalcji ustawiony jest ReadCommited, tranzakcje sa bardzo krotkie.
Ta sama aplikacja, ale skompilowana w D2007 na AnyDAC'u, z tymi samymi ustawieniami na tym samym serwerze chodzi na 60 stanowiskach bez zajakniecia.
Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL ale czy to jest rozwiaznie?
Jakie podpowiedzi?
Pozdrawiam
Bolo
wloochacz
Feb 29, 2016, 10:56:31 AM2/29/16
to
W dniu 2016-02-29 o 10:44, boloc...@gmail.com pisze:
tego samego połączenia.
Ale to już wiesz, bo przeczytałeś tekst wyjątku ;-)
> MARS w ustawieniach FireDAC'a jest wlaczony, nie ma zadnych cudow - ot kilka ADQuery, otwieranych w zaleznosci od potrzeb.
Tak, ale jak są otwierane i jak dokładnie dla każdego z nich jest
ustawione Connection i FetchOptions?
> A tnie sie niesamowicie - dodatkowo uruchomienie procedury skladowanej powoduje deadlock!!
A to już Twój problem, a nie FireDAC/MSSQL.
wszystko zależy co ta procedura robi, jak to robi i jak jest odpalana z
aplikacji - chodzi o transakcje.
Masz w tej procce set nocount on?
Ta procka aktualizuje dane w tabelach, na których są triggery?
Czy triggery mają set nocount on?
> poziom izoalcji ustawiony jest ReadCommited, tranzakcje sa bardzo krotkie.
> Ta sama aplikacja, ale skompilowana w D2007 na AnyDAC'u, z tymi samymi ustawieniami na tym samym serwerze chodzi na 60 stanowiskach bez zajakniecia.
Dziwne... Nie przypominam sobie jakiegoś BreakingChange w tym zakresie.
Wersja FireDAC z XE3?
I jeszcze jedno; jak masz ustawione FetchOptions.CursorKind,
ResourceOptions.DirectExecute, i jeszcze coś było z odpowiedzią serwera,
ale nie pamiętam co :/
> Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL ale czy to jest rozwiaznie?
Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient - nie z
czystym ODBC.
> Jakie podpowiedzi?
A jakiego klienta używa ta aplikacja?
Podpowiedzi;
1) FetchAll zawsze załatwia sprawę, ale musi być tryb blokujący do
otwierania dataseta
2) MARS = True, zawsze załatwia sprawę, pod warunkiem otwierania
datasetów podpiętych do tego samego połączenia w trybie blokującym i
używania NativeClient.
3) ConnectionPooling powinien zawsze załatwić sprawę.
--
wloochacz
> Witam wszystkich
>
> Wiem, ze kiedy ten watek byl, ale rozwiazenie tam sugerowane Fetch = fmAll jest obejsciem a nie rozwiazniem. :/
> Dlatego ponawiam watek (w pewnym sensie) - czemu w XE3 aplikacja an MSSQL 2005 wywala taki blad!
Dlatego, ze próbujesz otwierać dwa niezależne zestawy danych używając
>
> Wiem, ze kiedy ten watek byl, ale rozwiazenie tam sugerowane Fetch = fmAll jest obejsciem a nie rozwiazniem. :/
> Dlatego ponawiam watek (w pewnym sensie) - czemu w XE3 aplikacja an MSSQL 2005 wywala taki blad!
tego samego połączenia.
Ale to już wiesz, bo przeczytałeś tekst wyjątku ;-)
> MARS w ustawieniach FireDAC'a jest wlaczony, nie ma zadnych cudow - ot kilka ADQuery, otwieranych w zaleznosci od potrzeb.
ustawione Connection i FetchOptions?
> A tnie sie niesamowicie - dodatkowo uruchomienie procedury skladowanej powoduje deadlock!!
wszystko zależy co ta procedura robi, jak to robi i jak jest odpalana z
aplikacji - chodzi o transakcje.
Masz w tej procce set nocount on?
Ta procka aktualizuje dane w tabelach, na których są triggery?
Czy triggery mają set nocount on?
> poziom izoalcji ustawiony jest ReadCommited, tranzakcje sa bardzo krotkie.
> Ta sama aplikacja, ale skompilowana w D2007 na AnyDAC'u, z tymi samymi ustawieniami na tym samym serwerze chodzi na 60 stanowiskach bez zajakniecia.
Wersja FireDAC z XE3?
I jeszcze jedno; jak masz ustawione FetchOptions.CursorKind,
ResourceOptions.DirectExecute, i jeszcze coś było z odpowiedzią serwera,
ale nie pamiętam co :/
> Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL ale czy to jest rozwiaznie?
czystym ODBC.
> Jakie podpowiedzi?
A jakiego klienta używa ta aplikacja?
Podpowiedzi;
1) FetchAll zawsze załatwia sprawę, ale musi być tryb blokujący do
otwierania dataseta
2) MARS = True, zawsze załatwia sprawę, pod warunkiem otwierania
datasetów podpiętych do tego samego połączenia w trybie blokującym i
używania NativeClient.
3) ConnectionPooling powinien zawsze załatwić sprawę.
--
wloochacz
boloc...@gmail.com
Mar 2, 2016, 3:00:09 AM3/2/16
to
> Dlatego, ze próbujesz otwierać dwa niezależne zestawy danych używając
> tego samego połączenia.
> Ale to już wiesz, bo przeczytałeś tekst wyjątku ;-)
Wiem, ale... inne aplikacje dzialaja tak samo, jedno polaczenie do bazy i kilkanascie otwartych query i dziala bez zastrzezen!
> tego samego połączenia.
> Ale to już wiesz, bo przeczytałeś tekst wyjątku ;-)
> > MARS w ustawieniach FireDAC'a jest wlaczony, nie ma zadnych cudow - ot kilka ADQuery, otwieranych w zaleznosci od potrzeb.
> Tak, ale jak są otwierane i jak dokładnie dla każdego z nich jest
> ustawione Connection i FetchOptions?
> > A tnie sie niesamowicie - dodatkowo uruchomienie procedury skladowanej powoduje deadlock!!
> A to już Twój problem, a nie FireDAC/MSSQL.
> wszystko zależy co ta procedura robi, jak to robi i jak jest odpalana z
> aplikacji - chodzi o transakcje.
> Masz w tej procce set nocount on?
Nie mam :/ ale nigdy nie bylo i D2007 dzialo bez problemow...
Pokombinuje jeszcze z tym
> Ta procka aktualizuje dane w tabelach, na których są triggery?
> Czy triggery mają set nocount on?
> I jeszcze jedno; jak masz ustawione FetchOptions.CursorKind,
> ResourceOptions.DirectExecute, i jeszcze coś było z odpowiedzią serwera,
> ale nie pamiętam co :/
DirectExecute jest wylaczony
> ale nie pamiętam co :/
> > Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL ale czy to jest rozwiaznie?
> Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient - nie z
> czystym ODBC.
> Podpowiedzi;
> 1) FetchAll zawsze załatwia sprawę, ale musi być tryb blokujący do
> otwierania dataseta
> 3) ConnectionPooling powinien zawsze załatwić sprawę.
Dzieki za podpowiedzi
Bolo
wloochacz
Mar 2, 2016, 5:53:26 AM3/2/16
to
W dniu 2016-03-02 o 09:00, boloc...@gmail.com pisze:
niedogodności, poczytaj sobie na MSDN.
Kluczową sprawą jest włączenie *set nocount on*.
>>> MARS w ustawieniach FireDAC'a jest wlaczony, nie ma zadnych cudow - ot kilka ADQuery, otwieranych w zaleznosci od potrzeb.
>> Tak, ale jak są otwierane i jak dokładnie dla każdego z nich jest
>> ustawione Connection i FetchOptions?
> Wszystkie sa podpiete pod jedno Connection, FetchOptions bylo OnDeman - zmienilem na All, zaczelo dzialac.
To może działać poprawnie tylko i wyłącznie w jednym przypadku - kiedy w
tym samym czasie dla tego samego połączenia masz tylko jeden otwarty
kursor na serwerze.
SQL Profiler Twoim przyjacielem.
>>> A tnie sie niesamowicie - dodatkowo uruchomienie procedury skladowanej powoduje deadlock!!
>> A to już Twój problem, a nie FireDAC/MSSQL.
> No chyba jedna nie do konca moj :) bo...
Nie ma bo; mam wrażenie, że nie do końca rozumiesz jak to działa.
I tak, zważywszy na to że MSSQL działa tak a nie inaczej, to jest to
Twój błąd :)
>> wszystko zależy co ta procedura robi, jak to robi i jak jest odpalana z
>> aplikacji - chodzi o transakcje.
> Procedura robi update na jedenj tabeli, jest "opakowana" transakcjaNie
>> Masz w tej procce set nocount on?
> Nie mam :/ ale nigdy nie bylo i D2007 dzialo bez problemow...
> Pokombinuje jeszcze z tym
ZAWSZE musisz mieć to włączone przy MARS.
>> Ta procka aktualizuje dane w tabelach, na których są triggery?
>> Czy triggery mają set nocount on?
> Nie ma trigerow na tej tabli, nie sa potrzebne
>
>> I jeszcze jedno; jak masz ustawione FetchOptions.CursorKind,
> Domyslna wartosc ckAutomatic
Zostaw.
>> ResourceOptions.DirectExecute, i jeszcze coś było z odpowiedzią serwera,
>> ale nie pamiętam co :/
> DirectExecute jest wylaczony
Włącz.
>>> Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL ale czy to jest rozwiaznie?
>> Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient - nie z
>> czystym ODBC.
> Fakt, ze nie zaszkodzi - na kilku stanowiskach bez zmian w aplikacji (wylaczone FetchAll) pomoglo. Teraz jest wlaczone FetchAll i na innych bez upgradeu zaczelo dzialac, ale upgrade zrobie chyba na wszystkich.
Tylko, ze FetchAll to obosieczny miecz...
>> Podpowiedzi;
>> 1) FetchAll zawsze załatwia sprawę, ale musi być tryb blokujący do
>> otwierania dataseta
> W tej chwili jest FetchAll i tryb nie blokujacy i jakos dziala
>
>> 3) ConnectionPooling powinien zawsze załatwić sprawę.
> Hmm...opcja do przemyslenia i poczytania, nie uzywalem tego ale moze trzeba zaczac :)
>
> Dzieki za podpowiedzi
> Bolo
>
--
wloochacz
>> Dlatego, ze próbujesz otwierać dwa niezależne zestawy danych używając
>> tego samego połączenia.
>> Ale to już wiesz, bo przeczytałeś tekst wyjątku ;-)
> Wiem, ale... inne aplikacje dzialaja tak samo, jedno polaczenie do bazy i kilkanascie otwartych query i dziala bez zastrzezen!
Ale zmienił się AnyDAC i działanie MARSA ma pewne ograniczenia i
>> tego samego połączenia.
>> Ale to już wiesz, bo przeczytałeś tekst wyjątku ;-)
> Wiem, ale... inne aplikacje dzialaja tak samo, jedno polaczenie do bazy i kilkanascie otwartych query i dziala bez zastrzezen!
niedogodności, poczytaj sobie na MSDN.
Kluczową sprawą jest włączenie *set nocount on*.
>>> MARS w ustawieniach FireDAC'a jest wlaczony, nie ma zadnych cudow - ot kilka ADQuery, otwieranych w zaleznosci od potrzeb.
>> Tak, ale jak są otwierane i jak dokładnie dla każdego z nich jest
>> ustawione Connection i FetchOptions?
> Wszystkie sa podpiete pod jedno Connection, FetchOptions bylo OnDeman - zmienilem na All, zaczelo dzialac.
tym samym czasie dla tego samego połączenia masz tylko jeden otwarty
kursor na serwerze.
SQL Profiler Twoim przyjacielem.
>>> A tnie sie niesamowicie - dodatkowo uruchomienie procedury skladowanej powoduje deadlock!!
>> A to już Twój problem, a nie FireDAC/MSSQL.
> No chyba jedna nie do konca moj :) bo...
I tak, zważywszy na to że MSSQL działa tak a nie inaczej, to jest to
Twój błąd :)
>> wszystko zależy co ta procedura robi, jak to robi i jak jest odpalana z
>> aplikacji - chodzi o transakcje.
> Procedura robi update na jedenj tabeli, jest "opakowana" transakcjaNie
>> Masz w tej procce set nocount on?
> Nie mam :/ ale nigdy nie bylo i D2007 dzialo bez problemow...
> Pokombinuje jeszcze z tym
>> Ta procka aktualizuje dane w tabelach, na których są triggery?
>> Czy triggery mają set nocount on?
> Nie ma trigerow na tej tabli, nie sa potrzebne
>
>> I jeszcze jedno; jak masz ustawione FetchOptions.CursorKind,
> Domyslna wartosc ckAutomatic
>> ResourceOptions.DirectExecute, i jeszcze coś było z odpowiedzią serwera,
>> ale nie pamiętam co :/
> DirectExecute jest wylaczony
>>> Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL ale czy to jest rozwiaznie?
>> Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient - nie z
>> czystym ODBC.
> Fakt, ze nie zaszkodzi - na kilku stanowiskach bez zmian w aplikacji (wylaczone FetchAll) pomoglo. Teraz jest wlaczone FetchAll i na innych bez upgradeu zaczelo dzialac, ale upgrade zrobie chyba na wszystkich.
>> Podpowiedzi;
>> 1) FetchAll zawsze załatwia sprawę, ale musi być tryb blokujący do
>> otwierania dataseta
> W tej chwili jest FetchAll i tryb nie blokujacy i jakos dziala
>
>> 3) ConnectionPooling powinien zawsze załatwić sprawę.
> Hmm...opcja do przemyslenia i poczytania, nie uzywalem tego ale moze trzeba zaczac :)
>
> Dzieki za podpowiedzi
> Bolo
>
wloochacz
Krzysztof Szyszka
Mar 2, 2016, 1:12:34 PM3/2/16
to
> > > Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL ale czy to jest rozwiaznie?
> > Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient - nie z czystym ODBC.
> Fakt, ze nie zaszkodzi - na kilku stanowiskach bez zmian w aplikacji (wylaczone FetchAll) pomoglo.
> Teraz jest wlaczone FetchAll i na innych bez upgradeu zaczelo dzialac, ale upgrade zrobie chyba na
> wszystkich.
Obstawiałbym problem na styku wersja SQL Serwera i wersja klienta na komputerze dla nowszych
> > Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient - nie z czystym ODBC.
> Fakt, ze nie zaszkodzi - na kilku stanowiskach bez zmian w aplikacji (wylaczone FetchAll) pomoglo.
> Teraz jest wlaczone FetchAll i na innych bez upgradeu zaczelo dzialac, ale upgrade zrobie chyba na
> wszystkich.
FireDAC.
W zeszłym roku trafiłem na taki komunikat w prostym programie przykładowym (tworzonym w Delphi XE8)
przysłanym do mnie przez użytkownika TXDBGrida, który łączył się do jego serwera testowego w ...
Armenii :-)
Ponieważ problem, z którym zwracał się do mnie użytkownik, nie dotyczył tego błędu, a u niego ten
błąd nie
występował, to nie drążyłem tematu, bo podczas uruchamiania jego programu krokowo pod debuggerem,
ten błąd u mnie też nie występował. Konfiguracja komponentów FireDAC była domyślna.
--
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/
Join to "Delphi X-DBGrid Component Community"
https://plus.google.com/#communities/100842098152269100547
miab
Mar 2, 2016, 3:54:48 PM3/2/16
to
W dniu 2016-03-02 o 19:12, Krzysztof Szyszka pisze:
For an ODBC MSSQL database, set the ODBCAdvanced FDConnection parameter
value to MARS_Connection=YES. Otherwise, when you call the Open method
of FDTable, you will receive the following error:
[FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client
10.0]Connection is busy with results for another command.
Dosłownie wbić: MARS_Connection=YES w ODBCAdvanced.
Ogólnie rzecz biorąc W ZEOS mam mniej problemów z otwieraniem i
współdzieleniem tabel niż w FireDAC. Bywa ze wyraźnie więcej tabel w tym
systemowych mogę otworzyć w bazach z ZEOS-a(szczególnie w wersji 7.2.1
czy 7.3).
miab
>> > > Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL
>> ale czy to jest rozwiaznie?
>> > Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient -
>> nie z czystym ODBC.
>> Fakt, ze nie zaszkodzi - na kilku stanowiskach bez zmian w aplikacji
>> (wylaczone FetchAll) pomoglo.
>> Teraz jest wlaczone FetchAll i na innych bez upgradeu zaczelo dzialac,
>> ale upgrade zrobie chyba na
>> wszystkich.
>
> Obstawiałbym problem na styku wersja SQL Serwera i wersja klienta na
> komputerze dla nowszych FireDAC.
> W zeszłym roku trafiłem na taki komunikat w prostym programie
> przykładowym (tworzonym w Delphi XE8)
> przysłanym do mnie przez użytkownika TXDBGrida, który łączył się do jego
> serwera testowego w ... Armenii :-)
>
> Ponieważ problem, z którym zwracał się do mnie użytkownik, nie dotyczył
> tego błędu, a u niego ten błąd nie
> występował, to nie drążyłem tematu, bo podczas uruchamiania jego
> programu krokowo pod debuggerem,
> ten błąd u mnie też nie występował. Konfiguracja komponentów FireDAC
> była domyślna.
>
>
Może to:
>> ale czy to jest rozwiaznie?
>> > Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient -
>> nie z czystym ODBC.
>> Fakt, ze nie zaszkodzi - na kilku stanowiskach bez zmian w aplikacji
>> (wylaczone FetchAll) pomoglo.
>> Teraz jest wlaczone FetchAll i na innych bez upgradeu zaczelo dzialac,
>> ale upgrade zrobie chyba na
>> wszystkich.
>
> Obstawiałbym problem na styku wersja SQL Serwera i wersja klienta na
> komputerze dla nowszych FireDAC.
> W zeszłym roku trafiłem na taki komunikat w prostym programie
> przykładowym (tworzonym w Delphi XE8)
> przysłanym do mnie przez użytkownika TXDBGrida, który łączył się do jego
> serwera testowego w ... Armenii :-)
>
> Ponieważ problem, z którym zwracał się do mnie użytkownik, nie dotyczył
> tego błędu, a u niego ten błąd nie
> występował, to nie drążyłem tematu, bo podczas uruchamiania jego
> programu krokowo pod debuggerem,
> ten błąd u mnie też nie występował. Konfiguracja komponentów FireDAC
> była domyślna.
>
>
For an ODBC MSSQL database, set the ODBCAdvanced FDConnection parameter
value to MARS_Connection=YES. Otherwise, when you call the Open method
of FDTable, you will receive the following error:
[FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client
10.0]Connection is busy with results for another command.
Dosłownie wbić: MARS_Connection=YES w ODBCAdvanced.
Ogólnie rzecz biorąc W ZEOS mam mniej problemów z otwieraniem i
współdzieleniem tabel niż w FireDAC. Bywa ze wyraźnie więcej tabel w tym
systemowych mogę otworzyć w bazach z ZEOS-a(szczególnie w wersji 7.2.1
czy 7.3).
miab
wloochacz
Mar 3, 2016, 12:30:36 AM3/3/16
to
W dniu 2016-03-02 o 21:53, miab pisze:
Zresztą, Bolo napisał wyraźnie że ma to włączone.
> Ogólnie rzecz biorąc W ZEOS mam mniej problemów z otwieraniem i
> współdzieleniem tabel niż w FireDAC. Bywa ze wyraźnie więcej tabel w tym
> systemowych mogę otworzyć w bazach z ZEOS-a(szczególnie w wersji 7.2.1
> czy 7.3).
Rozumiem, że ZEOS też potrafi otwierać datasety w wątku pobocznym by design?
Bo to właśnie jest przyczyną takich problemów z MSSQL w FireDAC.
Otwierasz master i detale w ten sposób, oba mają równocześnie otwarty
kursor na serwerze dla tego samego połączenia i bach - problem gotowy.
A więc albo osobne połączenia dla datasetu, albo otwieranie i pobieranie
danych w trybie blokującym.
--
wloochacz
> Dosłownie wbić: MARS_Connection=YES w ODBCAdvanced.
To nie rozwiąże problemu przy pewnych ustawieniach FireDAC.
Zresztą, Bolo napisał wyraźnie że ma to włączone.
> Ogólnie rzecz biorąc W ZEOS mam mniej problemów z otwieraniem i
> współdzieleniem tabel niż w FireDAC. Bywa ze wyraźnie więcej tabel w tym
> systemowych mogę otworzyć w bazach z ZEOS-a(szczególnie w wersji 7.2.1
> czy 7.3).
Bo to właśnie jest przyczyną takich problemów z MSSQL w FireDAC.
Otwierasz master i detale w ten sposób, oba mają równocześnie otwarty
kursor na serwerze dla tego samego połączenia i bach - problem gotowy.
A więc albo osobne połączenia dla datasetu, albo otwieranie i pobieranie
danych w trybie blokującym.
--
wloochacz
wloochacz
Mar 3, 2016, 12:33:06 AM3/3/16
to
W dniu 2016-03-02 o 19:12, Krzysztof Szyszka pisze:
>> > > Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL
>> ale czy to jest rozwiaznie?
>> > Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient -
>> nie z czystym ODBC.
>> Fakt, ze nie zaszkodzi - na kilku stanowiskach bez zmian w aplikacji
>> (wylaczone FetchAll) pomoglo.
>> Teraz jest wlaczone FetchAll i na innych bez upgradeu zaczelo dzialac,
>> ale upgrade zrobie chyba na
>> wszystkich.
>
> Obstawiałbym problem na styku wersja SQL Serwera i wersja klienta na
> komputerze dla nowszych FireDAC.
Niekoniecznie.
>> ale czy to jest rozwiaznie?
>> > Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient -
>> nie z czystym ODBC.
>> Fakt, ze nie zaszkodzi - na kilku stanowiskach bez zmian w aplikacji
>> (wylaczone FetchAll) pomoglo.
>> Teraz jest wlaczone FetchAll i na innych bez upgradeu zaczelo dzialac,
>> ale upgrade zrobie chyba na
>> wszystkich.
>
> Obstawiałbym problem na styku wersja SQL Serwera i wersja klienta na
> komputerze dla nowszych FireDAC.
Wystarczy ODBC NativeClient w wersji 10.0 i powinno być OK w kwestii
biblioteki.
> W zeszłym roku trafiłem na taki komunikat w prostym programie
> przykładowym (tworzonym w Delphi XE8)
> przysłanym do mnie przez użytkownika TXDBGrida, który łączył się do jego
> serwera testowego w ... Armenii :-)
>
> Ponieważ problem, z którym zwracał się do mnie użytkownik, nie dotyczył
> tego błędu, a u niego ten błąd nie
> występował, to nie drążyłem tematu, bo podczas uruchamiania jego
> programu krokowo pod debuggerem,
> ten błąd u mnie też nie występował. Konfiguracja komponentów FireDAC
> była domyślna.
de-facto otwierały się te dane z opóźnieniem i właśnie dlatego nie
miałeś konfliktu i w efekcie nie zobaczyłeś błędu.
--
wloochacz
boloc...@gmail.com
Mar 3, 2016, 3:46:28 AM3/3/16
to
> >> Dlatego, ze próbujesz otwierać dwa niezależne zestawy danych używając
> >> tego samego połączenia.
> >> Ale to już wiesz, bo przeczytałeś tekst wyjątku ;-)
> > Wiem, ale... inne aplikacje dzialaja tak samo, jedno polaczenie do bazy i kilkanascie otwartych query i dziala bez zastrzezen!
> Ale zmienił się AnyDAC i działanie MARSA ma pewne ograniczenia i
> niedogodności, poczytaj sobie na MSDN.
> Kluczową sprawą jest włączenie *set nocount on*.
Właczenie czy wyłaczenie???
> >> tego samego połączenia.
> >> Ale to już wiesz, bo przeczytałeś tekst wyjątku ;-)
> > Wiem, ale... inne aplikacje dzialaja tak samo, jedno polaczenie do bazy i kilkanascie otwartych query i dziala bez zastrzezen!
> Ale zmienił się AnyDAC i działanie MARSA ma pewne ograniczenia i
> niedogodności, poczytaj sobie na MSDN.
> Kluczową sprawą jest włączenie *set nocount on*.
Własnie powyłączałem nocount w procedurach - zobaczymy jak to bedzie dzialac.
>
> >>> MARS w ustawieniach FireDAC'a jest wlaczony, nie ma zadnych cudow - ot kilka ADQuery, otwieranych w zaleznosci od potrzeb.
> >> Tak, ale jak są otwierane i jak dokładnie dla każdego z nich jest
> >> ustawione Connection i FetchOptions?
> > Wszystkie sa podpiete pod jedno Connection, FetchOptions bylo OnDeman - zmienilem na All, zaczelo dzialac.
> To może działać poprawnie tylko i wyłącznie w jednym przypadku - kiedy w
> tym samym czasie dla tego samego połączenia masz tylko jeden otwarty
> kursor na serwerze.
> SQL Profiler Twoim przyjacielem.
>
>
> >> wszystko zależy co ta procedura robi, jak to robi i jak jest odpalana z
> >> aplikacji - chodzi o transakcje.
> > Procedura robi update na jedenj tabeli, jest "opakowana" transakcjaNie
> >> Masz w tej procce set nocount on?
> > Nie mam :/ ale nigdy nie bylo i D2007 dzialo bez problemow...
> > Pokombinuje jeszcze z tym
> ZAWSZE musisz mieć to włączone przy MARS.
> >> ResourceOptions.DirectExecute, i jeszcze coś było z odpowiedzią serwera,
> >> ale nie pamiętam co :/
> > DirectExecute jest wylaczony
> Włącz.
>
> >>> Jedyne rozwiaznie jakie znalazlem to instalacja nowego klienta SQL ale czy to jest rozwiaznie?
> >> Na pewno nie zaszkodzi, bo MARS zadziała Ci tylko z NativeClient - nie z
> >> czystym ODBC.
> > Fakt, ze nie zaszkodzi - na kilku stanowiskach bez zmian w aplikacji (wylaczone FetchAll) pomoglo. Teraz jest wlaczone FetchAll i na innych bez upgradeu zaczelo dzialac, ale upgrade zrobie chyba na wszystkich.
> Tylko, ze FetchAll to obosieczny miecz...
Sproboje jeszcz instalacji nowego klienta sql - na kilku pierwszych stanowiskach zadzialalo, wiec moze to tez jest jakies wyjscie.
Pokombinuje, jak narazie nowa wersja aplikacji ruszyla i dziala w sieci lokalnej na kilku stanowiskach - stara wersja chodzi na ponda 60-ciu.
Nikt mi nie dzowni, nie widze bledow w logach...
Dzieki
Bolo
wloochacz
Mar 3, 2016, 11:31:43 AM3/3/16
to
W dniu 2016-03-03 o 09:46, boloc...@gmail.com pisze:
Inaczej; czy *set nocount on* włącza czy wyłącza?
Ma być ON, w pierwszej linii procedury/triggera!
Period.
Bo jak będzie off, to szykuj się na problemy ;-)
/ciach/
*Connection.GetInfoReport*
i zobacz co tam masz, powinno to wyglądać mniej więcej tak:
================================
Connection definition parameters
================================
MetaDefSchema=dbo
Password=*****
Name=dFLEX_DefConnection
DriverID=MSSQL
Pooled=True
LoginTimeout=5
MARS=Yes
MetaCaseIns=True
================================
Client info
================================
Loading driver MSSQL ...
Loading odbc32.dll driver manager
Creating ODBC environment handle
Searching for ODBC driver ...
Checking for ODBC driver [SQL SERVER NATIVE CLIENT 11.0] ...
Found [SQL Server Native Client 11.0] <<--- *To jest ważne i tak
powinno być*
Driver Manager version = 03.80.7601.0000
================================
Session info
================================
Current catalog =
Current schema = dbo
Driver name = sqlncli11.dll <<--- *I to też, wskazuje na użyty sterownik*
Driver version = 11.00.2100
Driver conformance = 3
DBMS name = Microsoft SQL Server
DBMS version = 12.00.4213
/ciach/
--
wloochacz
>>>> Dlatego, ze próbujesz otwierać dwa niezależne zestawy danych używając
>>>> tego samego połączenia.
>>>> Ale to już wiesz, bo przeczytałeś tekst wyjątku ;-)
>>> Wiem, ale... inne aplikacje dzialaja tak samo, jedno polaczenie do bazy i kilkanascie otwartych query i dziala bez zastrzezen!
>> Ale zmienił się AnyDAC i działanie MARSA ma pewne ograniczenia i
>> niedogodności, poczytaj sobie na MSDN.
>> Kluczową sprawą jest włączenie *set nocount on*.
> Właczenie czy wyłaczenie???
> Własnie powyłączałem nocount w procedurach - zobaczymy jak to bedzie dzialac.
Matko...
>>>> tego samego połączenia.
>>>> Ale to już wiesz, bo przeczytałeś tekst wyjątku ;-)
>>> Wiem, ale... inne aplikacje dzialaja tak samo, jedno polaczenie do bazy i kilkanascie otwartych query i dziala bez zastrzezen!
>> Ale zmienił się AnyDAC i działanie MARSA ma pewne ograniczenia i
>> niedogodności, poczytaj sobie na MSDN.
>> Kluczową sprawą jest włączenie *set nocount on*.
> Właczenie czy wyłaczenie???
> Własnie powyłączałem nocount w procedurach - zobaczymy jak to bedzie dzialac.
Inaczej; czy *set nocount on* włącza czy wyłącza?
Ma być ON, w pierwszej linii procedury/triggera!
Period.
Bo jak będzie off, to szykuj się na problemy ;-)
/ciach/
>> ZAWSZE musisz mieć to włączone przy MARS.
> Mars jest domyslnie wlaczony w XE3 - i byl wlaczony.
Nie był bym tego taki pewien; odczytaj sobie konfigurację Connection przez:
> Mars jest domyslnie wlaczony w XE3 - i byl wlaczony.
*Connection.GetInfoReport*
i zobacz co tam masz, powinno to wyglądać mniej więcej tak:
================================
Connection definition parameters
================================
MetaDefSchema=dbo
Password=*****
Name=dFLEX_DefConnection
DriverID=MSSQL
Pooled=True
LoginTimeout=5
MARS=Yes
MetaCaseIns=True
================================
Client info
================================
Loading driver MSSQL ...
Loading odbc32.dll driver manager
Creating ODBC environment handle
Searching for ODBC driver ...
Checking for ODBC driver [SQL SERVER NATIVE CLIENT 11.0] ...
Found [SQL Server Native Client 11.0] <<--- *To jest ważne i tak
powinno być*
Driver Manager version = 03.80.7601.0000
================================
Session info
================================
Current catalog =
Current schema = dbo
Driver name = sqlncli11.dll <<--- *I to też, wskazuje na użyty sterownik*
Driver version = 11.00.2100
Driver conformance = 3
DBMS name = Microsoft SQL Server
DBMS version = 12.00.4213
/ciach/
--
wloochacz
Krzysztof Szyszka
Mar 3, 2016, 12:57:12 PM3/3/16
to
> > Obstawiałbym problem na styku wersja SQL Serwera i wersja klienta na
> > komputerze dla nowszych FireDAC.
> Niekoniecznie.
> Wystarczy ODBC NativeClient w wersji 10.0 i powinno być OK w kwestii biblioteki.
Niekoniecznie :-)
> > komputerze dla nowszych FireDAC.
> Niekoniecznie.
> Wystarczy ODBC NativeClient w wersji 10.0 i powinno być OK w kwestii biblioteki.
Ja mam akurat sterownik w wersji 10.00.10586.00, a błąd połączenia występował.
> Nie występował, po pod debuggerem w trybie krokowym sprawiłeś, że de-facto otwierały się te dane z
> opóźnieniem i właśnie dlatego nie miałeś konfliktu i w efekcie nie zobaczyłeś błędu.
i dlatego pierwsze co zrobiłem, to uruchomiłem ten program pod debuggerem
otwierając kolejne DataSety w trybie krokowym.
0 new messages