roafacturare/docs/cercetare/rec_inainte_de_stoc.md

De ce la test crapa (View Parameter) si in productie merge — INAINTE_DE_STOC

Investigatie read-only, 08.08.2026. Intrebare de la Marius: acelasi tipar DO ... WITH gnAn, gnLuna exista in productie la COMUN\programe\oproceduri_stocuri.prg:35,130,207 — de ce nu s-a manifestat niciodata acolo?

Raspuns

Varianta 1, confirmata prin citirea intregului cod al procedurii apelate: inofensiv prin constructie. Pe acest lant nu exista niciun ?gnAn/?gnLuna (bind marker SQL) — deci pasarea prin referinta, desi masca numele gnAn/gnLuna in interiorul procedurii apelate, nu are ce sa strice.

Dovada, pas cu pas

1. Apelul: oproceduri_stocuri.prg:35,130,207 — DO INAINTE_DE_STOC WITH gnAn, gnLuna, tnTipGest, lnStocObinv in oinainte_de.prg.
2. Procedura apelata: COMUN\programe\oinainte_de.prg:356-411, PROCEDURE INAINTE_DE_STOC, semnatura Parameters tnAn, tnLuna, tnTipGest, tnStocObinv, tcListaIdGestiuni. Deci gnAn ajunge accesibil in interior doar sub numele local tnAn (si gnLuna sub tnLuna) — exact tiparul care facea TYPE('gnAn')='U' in testul de ieri.
3. Singurul SQL din procedura e la oinainte_de.prg:389-390:

   lcSql = "select pack_inainte_de.inainte_de_stoc(" + Alltrim(Str(tnAn)) + "," + Alltrim(Str(tnLuna)) + "," + ;
       Alltrim(Str(tnTipGest)) + "," + Alltrim(Str(tnStocObinv)) + "," + Iif(Isnull(gnIdSucursala), "null", Alltrim(Str(gnIdSucursala))) + "," + ;
       Iif(Empty(Nvl(m.lnIdGestiune, '')), "null", Alltrim(Str(lnIdGestiune))) + ") as valoare from dual"
   

   Toti termenii intra prin concatenare (Alltrim(Str(...))), inclusiv tnAn/tnLuna — cele masate. Zero caractere ? in acest string. gnIdSucursala apare si el, dar tot prin concatenare, nu ca bind marker — deci nici acolo nu conteaza ca e vizibil sau nu global.
4. Procedura nu face niciun alt DO ... WITH mai departe — bucla For lnGestiune = 1 To lnGestiuni apeleaza direct goExecutor.oExecute(lcSql, lcCursor) (executie Oracle), nu alta procedura VFP. Lantul se opreste aici; nu exista o veriga suplimentara unde tnAn/tnLuna sa piarda contextul.

Concluzie: mecanismul care bloca testul (VFP incearca sa lege ?gnAn la o variabila devenita 'U' si deschide dialogul nativ "View Parameter") nu are niciun ?gnAn/?gnLuna de legat pe acest lant — nu pentru ca variabila ar fi vizibila, ci pentru ca nimeni nu o cere prin acel mecanism. Utilizatorul nu vede dialogul pentru ca bug-ul latent (pasarea prin referinta) exista, dar consecinta lui (bind marker nelegat) nu e declansata de acest cod.

Verdict

Inofensiv, cazul specific din intrebare. Nu e bug latent — e cod scris corect din intamplare (sau prin obisnuinta autorului de a concatena SQL-ul in loc sa foloseasca bind markers), care absoarbe fara sa observe efectul secundar al DO ... WITH.

Cautare extinsa: aceeasi familie in restul COMUN\programe si COMUN\clase

Cautat tiparul complet (ambele conditii): DO ... WITH <variabila globala> (fara paranteze, deci prin referinta) si acelasi nume aparand ca ?<variabila> undeva accesibil pe lantul de apel.

Inventarul complet de apeluri DO ... WITH <global g*> neconditionate (comentariile *DO ... nu conteaza, cod mort):

Apel	Fisier:linie	Verdict
DO INAINTE_DE_STOC WITH gnAn, gnLuna, tnTipGest, lnStocObinv	oproceduri_stocuri.prg:35,130,207	Inofensiv — vezi mai sus
DO fisa_magazie_fifo WITH gnTipGest,pnIdGestiune,pcNumeGestiune,PcCodul	rulaje.vc2:8243	Inofensiv — vezi mai jos
*DO schimba_firma WITH gnHandle,GCS,lcschemaParola	ostartfirma.prg:168	cod mort (comentat)
*DO schimba_firma WITH gnHandle,lcSchema,...	ferestre_comune.vc2:859, ferestre_oracle.vc2:858	cod mort (comentat)

fisa_magazie_fifo (orapoarte.prg:266-..., Lparameters tnTipGest, tnIdGestiune, tcNumeGestiune, tnIdArticol, tcSerie): gnTipGest ajunge accesibil doar sub tnTipGest. Cautare \?gnTipGest\b in tot COMUN gaseste 8 hituri, niciunul in orapoarte.prg — toate in fisiere fara legatura cu acest lant de apel (gest_selectii.db2, oproceduri_facturare.prg, configurare.vc2, oschimbare_pret.vc2, apeluri din alte fluxuri, nu din fisa_magazie_fifo). Functia foloseste tnTipGest doar prin comparatie directa (If tnTipGest = 6) si transmis mai departe ca parametru catre caut_gestiune(tnTipGest, gnIdUtil) — niciodata ca bind marker SQL. Inofensiv, acelasi motiv ca la INAINTE_DE_STOC.

Nu exista alt caz in COMUN\programe / COMUN\clase unde ambele conditii (DO...WITH pe un global + ?acelasi_nume pe lantul de apel) sa se intalneasca simultan.

Gasit in cautare, dar NU pe acest tipar (semnalat totusi)

oinainte_de.prg:258, procedura test_casa:

lcSql = [select PACK_INAINTE_DE.TEST_CASA(?gnAn,?gnLuna,?pcContTestCasa,?gnIdSucursala) AS VALOARE FROM DUAL]

Foloseste ?gnAn/?gnLuna/?gnIdSucursala ca bind markers reali. Dar apelul catre test_casa (ocasabanca.prg:66: Do test_casa With lcCont In oinainte_de.prg) paseaza doar lcCont — gnAn/gnLuna nu sunt deloc argumente, deci nu sunt mascate pe acest lant. Nu se incalca conditia ceruta (ambele trebuie sa se intample impreuna), deci nu e cazul cautat — dar e o structura fragila: daca in viitor cineva ar adauga gnAn/gnLuna ca parametri suplimentari la test_casa fara paranteze, ar reproduce exact blocajul de ieri, de data asta in productie (dialogul "View Parameter" vazut de utilizator). Nu e remediat — doar semnalat, in afara scopului intrebarii.

Remediu propus (NEAPLICAT)

Niciunul necesar pentru cazurile gasite — sunt inofensive prin constructie. Daca se doreste totusi o plasa de siguranta impotriva viitoarelor regresii de acest tip: paranteze la orice DO ... WITH care paseaza globale catre o procedura ale carei SQL-uri sunt necunoscute/in schimbare — DO INAINTE_DE_STOC WITH (gnAn), (gnLuna), tnTipGest, lnStocObinv — cost zero, elimina clasa de bug la sursa. Nu s-a aplicat nicio modificare de cod — cod de productie neatins, conform interdictiei.