🚀 go-pugleaf

W dniu 2016-02-29 o 10:44, bolocorp99@gmail.com pisze:
> 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 
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

> 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!

> > 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.


> > 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...

> 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

W dniu 2016-03-02 o 09:00, bolocorp99@gmail.com pisze:
>> 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*.

>>> 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

> > > 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.


-- 
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 

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.
> 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:
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

W dniu 2016-03-02 o 21:53, miab pisze:
> 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).
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

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.
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.
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.

-- 
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.

> 
> >>> 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.
Mam, Profilera znam :)

> 

> 
> >> 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.
Mars jest domyslnie wlaczony w XE3 - i byl wlaczony.

 
> >> ResourceOptions.DirectExecute, i jeszcze coś było z odpowiedzią serwera,
> >> ale nie pamiętam co :/
> > DirectExecute jest wylaczony
> Włącz.
Właczyłem

> 
> >>> 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...
Wiem! Dlatego szukam rozwizania bez FetchAll.

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

W dniu 2016-03-03 o 09:46, bolocorp99@gmail.com pisze:
>>>> 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...
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:
*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

> > 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 :-)
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.

Tego akurat można się domyślić po przeczytaniu samego komunikatu o błędzie
i dlatego pierwsze co zrobiłem, to uruchomiłem ten program pod debuggerem
otwierając kolejne DataSety w trybie krokowym.

-- 
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