SCHRECK wrote Am de rezolvat o problema urgenta. Voi explica prin exemplu ce am si se vreaua sa obtin Am doua fisiere PERSONAL.DBF care arata in felul urmator CNP NUME CNP C(13) 11 POP IOAN 22 MOIS MIA RATE.DBF CNP AVANS RATA CNP C(13) 11 250 50 11 0 50 22 300 70 22 0 70 22 0 70 Deci prima inregistrare pt.un cnp nou contine avansul restul 0, iar campul rata contine aceasi valoare Trebuie sa culeg datele din cele 2 fisiere si sa obtin un fisier care sa contina NUME AVANS RATA POP IOAN 250 50 MOIS MIA 300 70 In VFP versiunea 6 am rezolvat problema cu comanda SELECT p.nume,SUM(r.avans) AS avans,r.rata FROM personal P,rate R WHERE ALLTRIM(P.CNP)==ALLTRIM(R.CNP) GROUP BY nume ORDER BY nume INTO TABLE fisier Am obtinut ceea-ce am vrut Folosind aceasi comanda in VFP9 SP2 primesc mesajul de eroare SQL GROUP BY: clause is missing or invalid Eroarea dispare daca scriu GROUP BY nume,avans,rata in schimb fiecare nume apare de 2 ori Nu inteleg de ce in VFP6 functioneaza in si in VFP9 nu Va rog sa-mi spuneti cum trebuie scris in VFP9 sa functioneze si de ce clauza GROUP BY se comporta diferit in cele 2 versiuni

Am mai scris explicatia de cateva ori, da' mi-e lene sa caut. :) Cazul tau este particular - ai aceeasi valoare in campul "rata". Engine-ul SQL n-are de unde sa stie asta. Daca nu specifici campul ala in Group By, VFP6 pune la intamplare una din valori. (in realitate, nu chiar la intamplare, ci pe prima in ordine fizica). Pentru ca ai aceeasi valoare, nu te afecteaza, dar daca ai avea valori diferite n-ai vrea ca VFP sa decida in locul tau ce valoare apare acolo.

Asta era o problema. Serios. Nici un server SQL n-o sa accepte o astfel de sintaxa. Si daca vei vrea vreodata sa portezi aplicatia ta pe un server SQL o sa-ti crape toate SELECT-urile de genul asta. In VFP9 problema a fost eliminata (era bad design anyway) dar au introdus clauza SET ENGINE BEHAVIOR pentru compatibilitate, ca deh, nu toata lumea are chef sa corecteze SQL-urile alea.

O sa dau un exemplu din care se vede ca lipsa obligativitatii clauzei Group By este nashpa. Sa zicem ca ai o tabela de facturi cu urmatoarea structura:

Id      IdClient    NrFactura     DataFactura   ValoareTotala

1            1             0001          15.05.2011        100
2            1             0002          16.05.2011        150
3            2             0003          01.05.2011          75
4            2             0004          03.05.2011        125

Daca executi urmatorul SELECT:

Select IdClient, NrFactura, DataFactura, Sum(ValoareTotala) From Facturi Group By IdClient, VFP6 o sa-ti intoarca un rezultat de genul:

1    0001   15.05.2011     250
2    0003   01.05.2011     200

Acum uite-te la rezultat si intreaba-te: exista vreo factura cu numarul 0001 din data 15.05.2011 cu suma 250? Nu, nu exista. Altfel spus, numarul si data facturi n-au nici o relevanta in context. Sunt niste cifre care nu-ti trebuie. Si asta e cazul fericit. VFP ar putea sa-ti puna numarul facturii citit dintr-o inregistrare si data facturii citita din alta inregistrare si o sa obtii o varza in setul rezultat.

Ori le pui in Group By, ori le dai afara. Daca aveai valori diferite in campul RATA ce faceai?

Nu prea sunt de acord cu ce spui. Peste 10 ani, cand o sa ai experienta, nici tu n-o sa mai fii de acord cu ce spui acum. :) Ideea e ca clientul poa'sa zica ce vrea el. Clientul nu e programator, nu e DBA. N-are de unde sa stie. El cunoaste problemele lui - nu-i platesc clientii la timp, i-au cazut masinile de distributie, aia de la leasing il freaca la cap cu ratele, etc etc etc. Sarcina proiectarii bazei de date iti revine tie, nu lui. Daca stai in baza clientului ajungi sa reproiectezi baza aia de date, cu toate problemele aferente (asa cum ai punctat mai sus).

Uite cum as fi facut eu tabela aia a ta: campul avans NU are ce cauta in tabela aia. Sa-ti spun si de ce: avansul este o chestie one-time-only, rata e in fiecare luna. Tu ai reusit sa creezi o coloana in care ai completat un singur rand pentru fiecare angajat, iar restul (daca angajatul are 100 de rate - restul inseamna 99 de randuri) contin zero. Design neglijent, risipa de spatiu, risipa de IO, risipa de procesor la interogari. De ce? pentru ca l-ai ascultat orbeste pe client si nu ai filtrat informatiile de la el prin propriul tau discernamant. Sigur, la inceput (banuiesc ca esti tanar) n-ai de unde sa stii; trebuie sa o iei in freza de cateva ori apoi incet incet iti dai seama ca dupa ureche nu merge. Ma rog, cunosc oameni care au 50 de ani si inca n-au ajuns la concluzia asta, ci continua sa "urecheasca" tot felul de baze de date de doi lei.

Eu as fi facut trei tabele:

Personal.dbf - cu campurile ID, CNP, NUME, PRENUME
Avans.dbf - cu campurile ID, IDPERSONAL, VALOARE, DATA
Rate.dbf - cu campurile ID, IDPERSONAL, RATA, DATA

Problema ta s-ar fi rezolvat cu o instructiune de genul SELECT Personal.Nume, Personal.Prenume, (Select valoare from avans where avans.idpersonal = personal.id) As Avans, sum(rate.rata) From Personal  Left Join rate On personal.id = rate.idpersonal group by personal.id, personal.nume, personal.prenume

(te rog sa remarci subquery-ul din lista de campuri).

Si obtin fix tabela ta, cu group by pe ce-mi trebuie, fara dureri de cap.

Daca ala o sa vrea vreodata suma de rate, un select simplu rezolva problema. Daca vrea suma de avansuri, un select simplu rezolva problema. Daca vrea mai stiu eu ce-i trece prin cap cu campurile de avans si de rata, un select (relativ) simplu rezolva problema.

Si asta pentru ca in designul asta ENTITATILE sunt izolate in tabele proprii (forma a 3-a de normalizare, da' deh, trebuie sa mai si citim, nu merge doar dupa ureche, fratioare). Tu ai amestecat in tabela ta doua lucruri diferite si e normal sa ai dificultati cand vrei sa faci calcule diferite pe fiecare in parte. Si da, tocmai ai ajuns intr-o astfel de situatie.