Eroare situatie client

[vasilescud685]

Buna ziua.

Probleme cu Saga 582 client-server

Un client ne cere o fisa client cu toate facturile/incasarile de cand colaboram (2019), se pare ca la ei lipseste ceva si vor punctaj.
Am intrat pe Situatie clienti din meniu pentru a lista fisa aceea si a o transmite ( Situatie facturi + incasari )
Din pacate, desi generarea datelor este destul de rapida avand in vedere volumul de date ( 72 000 de clienti ), ulterior se blocheaza dupa ce am cautat clientul, am trecut pe subpagina de "Facturi - ...client..." si am dat click pe butonul "Tiparire facturi + incasari".
Ce face dureaza mult, deoarece datele sunt accesibil instant pe tabelele de facturi/incasari si se pot exporta in excel
Se blocheaza, windows-sul zice a "sc.exe is not responding" si daca aleg "wait for program to respond" continua sa "macine" pana ocupa tot spatiul de pe disc, vreo 400 gigabytes.
Daca aleg "Try to restore program" da o eroare SQL si iese. Din analiza SQL-ului am remarcat ca se face un join intre tabela de clienti cu tabela de inregistrari contabile "ON clienti.analitic = registru.id_cont_d"
Problema e ca noi avem acelasi cont analitic la clientii de pe online, majoritatea. Asa ca acel JOIN intre tabela de clienti cu tabela de articole contabile rezulta in ceva ce depaseste capacitatea de stocare.

Momentan am salvat in excel si am facut manual fisa aceea.

Dorin Vasilescu

eroare_saga.jpg (131.52 KiB) Vizualizat de 3747 ori

[vasilescud685]

Update:
Rularea acelui SQL cu VFP pe date din DBF-uri restaurate inainte de trecerea pe client-server da de asemenea eroare "File is too large"

Un experiment cu urmatorul SQL da rezultat instantaneu cu incasarile pe acel cod client pana la data specificata:

Cod: Selectaţi tot

m.codClient = '39922855'
m.plodata2 = {^2024-11-30}
m.contclient = '4111.00008'
select ;
	  registru.id_nota, clienti.cod, registru.data, cod_valuta ;
	, registru.id_cont_d as cont, clienti.analitic, sum(registru.suma) as incasari ;
	, max(registru.fel_d) as fel_d ;
from ;
	clienti join registru on clienti.cod = registru.cod ;
where ;
	clienti.cod = ?m.codClient and registru.data <= ?ploData2 and registru.id_cont_c = ?m.contClient  ;
	and registru.id_nota > 0 ;
group by id_nota, clienti.cod, registru.data, cod_valuta, cont, analitic

Dorin Vasilescu

[Administrator]

Comanda nu are cum sa dureze prea mult, indiferent de tipul bazei de date. Trimite baza de date pe mail, pentru verificare.

[vasilescud685]

Incorecta afirmatia ca nu poate dura mult. Am testat in mediul VFP cu tabele de dinainte de migrare pe client-server. Cursorul temporar depaseste 2 GB si VFP da eroare.
In masura in care toti clientii de online au acelasi cont analitic, un join cu tabela registru care are sute de mii de inregistrari da acest rezultat. Un join pe baza cod client e instantaneu indiferent de perioada.
Presupun ca s-a schimbat ceva la cel SQL de la versiunile anterioare, am mai avut solicitari anul acesta de fise si nu am avut erori, chiar daca generarea raportului pentru listare a durat cam mult.
Am dorit sa evitam zeci/sute de mii de analitice clienti (deoarece majoritatea au una sau cateva facturi/incasari) si se pare ca asta e cauza.
Baza de date are cam 500 MB, cam mare de trimis.

[ovidiuo]

@vasilescud685: ... în caz că nu te-ai prins, @Administrator este boss-ul ăl mare de la SAGA .. dacă vrei problema rezolvată, trimite baza ! Folosește WeTransfer sau alt serviciu de genu' ăsta !

[vasilescud685]

La verificare date toate bifele sunt pe OK.
Nu vad cum s-ar putea rezolva fara sa fie modificate interogarile SQL, avand in vedere cum avem configurate conturile la clientii online (acelasi analitic pentru zeci de mii, in viitor poate sute de mii).
Credeti-ma ca stiu ce spun, chiar daca am trecut de la programare la antreprenoriat nu am uitat VFP si SQL.
Apreciez SAGA, este excelent, dar poate fi optimizat si pentru unele situatii particulare ca aceasta.

Am cronometrat: 13 secunde procesarea initiala pentru toti clientii si afisarea datelor
2 secunde afisare in subpagina clientului a facturilor si incasarilor pentru un client anume
generarea unui raport pentru facturile/incasarile deja afisate duce la blocare sau eroare disk full

Dorin Vasilescu

[ciucam288]

dece nu fragmentati procesarea de date?
eventual cu export si cu refacerea altor baze doar cu informatia dorita?

[vasilescud685]

Am exportat in excel si am combinat inregistrarile de facturi/incasari pentru clientul respectiv. Care au fost afisate aproape instantaneu BTW.

[hucecd]

Comanda nu are cum sa dureze prea mult, indiferent de tipul bazei de date. Trimite baza de date pe mail, pentru verificare.

Aveti raspuns pentru rezolvare. Daca doriti rezolvare procedati intocmai. Altfel...

[vasilescud685]

Am rezolvat cu fisa prin export excel.
In ceea ce priveste rezolvarea din punct de vedere al datelor, sunt doua posibilitati.
Varianta 1: Un analitic distinct pentru fiecare client in baza de date. Asta ar insemna sa o trimitem si sa o modifice cineva de la SAGA. Nu agreez acesta solutie, vom avea zeci de mii de analitice la clienti ocazionali online, marea majoritate cu cateva facturi si incasari.
Varianta 2: Modificarea SQL sa tina cont si de codul client deja existent in tabela registru. Daca observatia mea este valida, eu si cei care au aceeasi abordare cu conturile analitice la clienti ocazionali vom observa la o versiune viitoare cum o situatie a unui client este generata instantaneu chiar la sute de mii de inregistrari.

Dorin Vasilescu

PS: Nu sunt profan in VFP si SQL, sau cel putin asa eram considerat candva.