B_gd_n[ ]Sahlean:

[
Totuşi aici există tone de cod sursa pentru VB6, inclusiv pentru module/componente tip autoupdate.
+
Automatically Updating Visual Basic 6 Applications: Part I
Automatically Updating Visual Basic 6 Applications: Part II

Nu discut de linkurile de MSDN, pe care mi le-ai dat, pentru ca scriu :
"This article shows how you can add automatic updating functionality to your existing Visual Basic 6.0 applications, using features now available with the .NET Framework 2.0. (10 printed pages)"

Iar celelalte coduri sursa ... marturisesc ca nu le-am incercat pe toate ... dar nu am reusit sa fac nimic serios care sa poata fi reutilizat.

Eu am programat in VB de cind era VB3 , am reusit sa fac ceva cu clasele din VB4, in VB5 am prins gustul la API-uri , VB6 m-a dezamagit ( o spoiala peste VB5 ) ... dar nu am reusit sa fac un auto-update care sa il refolosesc dintr-o aplicatie in alta...

Desi discutia este/devine obsolete, tu ai facut asa ceva cu succes ?

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

B_gd_n[ ]Sahlean:

În concluzie, pentru asigurarea persistenţei (dpmdv) sunt necesare cel puţin două nivele de abstractizare: business layer (clase tip business objects) şi data layer (clase de persistenţă).

Sunt de acord cu tine . Dar chiar asa faci ? Tendinta actuala ( vezi partial classes si LINQ 2 SQL) este sa te lase sa scrii aceeasi clasa in 2 fisiere separate - una de persistenta si una de BL

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

B_gd_n[ ]Sahlean:

Carte este (asa cum am scris mai sus) "Applying UML and patterns", autor Craig Larman.

mersi mult, am sa o caut.

Gherry:

B_gd_n[ ]Sahlean:

Carte este (asa cum am scris mai sus) "Applying UML and patterns", autor Craig Larman.

mersi mult, am sa o caut.

damn.. aia e de nivel intermediar - avansat.. speram la ceva scris pt bolovani dar o sa incerc sa vad cu ce se mananca, poate am noroc si se prinde si de mine ceva

ignatandrei:

B_gd_n[ ]Sahlean:

[
Totuşi aici există tone de cod sursa pentru VB6, inclusiv pentru module/componente tip autoupdate.
+
Automatically Updating Visual Basic 6 Applications: Part I
Automatically Updating Visual Basic 6 Applications: Part II

Nu discut de linkurile de MSDN, pe care mi le-ai dat, pentru ca scriu :
"This article shows how you can add automatic updating functionality to your existing Visual Basic 6.0 applications, using features now available with the .NET Framework 2.0. (10 printed pages)"
...

Corect, tocmai din acest motiv acele 2 link-uri sunt secundare.

ignatandrei:

... tu ai facut asa ceva cu succes ?

De succes nu stiu daca este dar am apelat la o metodă simplistă:
[1] pe un server aveam un director partajat doar pentru citire (read-only share) care conţinea toate fişierele necesare aplicatiei client plus un fisier ver.txt. Fisierul ver.txt continea versiunea aplicatiei client.
[2] pe fiecare computer unde era instalata aplicatia client era instalat si un programel actualizare.exe care verifica daca aplicatia client ruleaza sau nu si apoi citea local din registrii versiunea si o compara cu versiunea de pe server din ver.txt ! Daca versiunea locala < versiunea de pe server atunci FileCopy sursă, destinaţie !

B_gd_n[ ]Sahlean:

ignatandrei:

... tu ai facut asa ceva cu succes ?

De succes nu stiu daca este dar am apelat la o metodă simplistă:
[1] pe un server aveam un director partajat doar pentru citire (read-only share) care conţinea toate fişierele necesare aplicatiei client plus un fisier ver.txt. Fisierul ver.txt continea versiunea aplicatiei client.
[2] pe fiecare computer unde era instalata aplicatia client era instalat si un programel actualizare.exe care verifica daca aplicatia client ruleaza sau nu si apoi citea local din registrii versiunea si o compara cu versiunea de pe server din ver.txt ! Daca versiunea locala < versiunea de pe server atunci FileCopy sursă, destinaţie !

Inteleg ca aplicatia era monolitica ... nu era impartita in dll-uri si nu avea probleme de inregistrare de dll-uri, BD diferite care se puteau schimba dinamic, rapoarte definite in Crystal s.a.m.d.

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

ignatandrei:

B_gd_n[ ]Sahlean:

ignatandrei:

... tu ai facut asa ceva cu succes ?

De succes nu stiu daca este dar am apelat la o metodă simplistă:
[1] pe un server aveam un director partajat doar pentru citire (read-only share) care conţinea toate fişierele necesare aplicatiei client plus un fisier ver.txt. Fisierul ver.txt continea versiunea aplicatiei client.
[2] pe fiecare computer unde era instalata aplicatia client era instalat si un programel actualizare.exe care verifica daca aplicatia client ruleaza sau nu si apoi citea local din registrii versiunea si o compara cu versiunea de pe server din ver.txt ! Daca versiunea locala < versiunea de pe server atunci FileCopy sursă, destinaţie !

Inteleg ca aplicatia era monolitica ... nu era impartita in dll-uri si nu avea probleme de inregistrare de dll-uri, BD diferite care se puteau schimba dinamic, rapoarte definite in Crystal s.a.m.d.

Are 3 componente ActiveX OCX care au totuşi interfaţa stabilă => nu este necesară reînregistrarea OCX-urilor.
Iar rapoartele CrystalReports sunt incorporate in Exe.

Mai bine spus, la OCX daca modificam ceva atunci modificam implementarea si nu interfata (publica se subintelege; "Program to an interface, not an implementation").

Gherry:

Eu eram ferm convins ca vorbim despre situatii care nu sunt acoperite de userii de windows de ex: intr-un magazin pot sa fie in acelasi timp mai multi agenti de vanzari care iregistreaza operatiile pe acelasi calculator caz in care ar fi aberant sa creem conturi de win pt fiecare si sa ii punem sa dea switch user de fiecare data.

Conturi de Windows pentru fiecare angajat sint ceva elementar in orice mediu. As vrea sa stiu ce gasesti 'aberant' in cel mai fundamental principiu de securitate de pe platforma pe care o folosesti. Si nu este nevoie de switch pentru fiecare utilizator, exista atit infrastructura de runas /user in Windows cit si posibilitatea de a integra in aplicatie schimbarea contextului curent prin LogonUser.
Bazele securitatii nu se impelemnteaza dupa 'cheful' clientilor ci prin respectarea principiilor de baza (autentificare pe baza de parola, autorizare, access controlat la 'asset'urile controlate de securitate etc). In afara cazului in care esti un specialist in securitate (si in mod sigur nu esti) orice altceva este doar o fatada goala care mascheaza exploit-uri banale, o joaca in a fi depasita pentru oricine are un interes fie si minor.

Gherry:

sau daca avem o aplicatie care lucreaza pe web sunt curios cum rezolvi problema folosind exclusiv modul de securitate SQL Server..

Userii de Web in majoritatea cazurilor nu au nimic de-a face cu autorizarea in access la date (sau orice alte resurse) ci doar cu autentificarea in aplicatie. In mediul gen web (numar mare de utilizatori, necunoscut dinainte, fara disctinctie intre ei) un 'user' nu e un 'database principal'. Cind am creat userul 'rremus' la sqlserver.ro in mod sigur nu am primit GRANT pe nici un obiect din baza de date. S-a creat un record al acestui user intr-o tabela, dar acesta nu este in nici un fel implicat in drepturile de access din baza de date. Toate drepturile sint acordate aplicatiei Web. Eventual aplicatia are citeva roluri definite (ex. user simplu vs. moderator) care au access la mai multe sau mai putzine module, dar astea nu se reflecta in mod sigur in nici un fel asupra drepturilor efective din baza de date. De exemplu daca in aceasi baza de date se adauga o tabela de catre o alta aplicatie, nu exista nici un mod de a restrictiona 'userii' Web sa o acceseze, intr-ucit ei nu exista ca 'security pricipals'. Ce se restrictioneaza este accessul aplicatiei Web.
In aceste cazuri nu vorbesti despre securitate in baza de date, ori discutia noastra era pornita de la avantajele SQL vs. proceduri si un argument a fost controlul accesului la proceduri prin useri si GRANT-uri. Argumentul tau (useri Web)  este nu are legatura cu discutia noastra (GRANT-uri in baza de date).

---

http://rusanu.com

rremus:

 Cind am creat userul 'rremus' la sqlserver.ro in mod sigur nu am primit GRANT pe nici un obiect din baza de date. S-a creat un record al acestui user intr-o tabela, dar acesta nu este in nici un fel implicat in drepturile de access din baza de date. Toate drepturile sint acordate aplicatiei Web. Eventual aplicatia are citeva roluri definite (ex. user simplu vs. moderator) care au access la mai multe sau mai putzine module, dar astea nu se reflecta in mod sigur in nici un fel asupra drepturilor efective din baza de date. De exemplu daca in aceasi baza de date se adauga o tabela de catre o alta aplicatie, nu exista nici un mod de a restrictiona 'userii' Web sa o acceseze, intr-ucit ei nu exista ca 'security pricipals'. Ce se restrictioneaza este accessul aplicatiei Web.
In aceste cazuri nu vorbesti despre securitate in baza de date, ori discutia noastra era pornita de la avantajele SQL vs. proceduri si un argument a fost controlul accesului la proceduri prin useri si GRANT-uri. Argumentul tau (useri Web)  este nu are legatura cu discutia noastra (GRANT-uri in baza de date).

cand am zis de aplicatia web aveam in cap situatii cum ar fi faptul ca tu poti sa editezi doar posturile tale si eu pe ale mele.. idee care eu zic ca se poate repeta si in alte situatii.

PS: nu am pretentia ca as fi specialist in securitate (in mod cert nu sunt) insa nu obisnuiesc sa ma multumesc cu un raspuns care nu acopera aspecte care ma interseaza chiar daca este perfect valid in alte situatii, motiv pt care prefer sa extind discutia in asa fel incat sa cuprinda tot ce ma intereseaza decat sa ignor anumite ramificatii.

in alta ordine de idei IT-ul nu este o stiinta atat de fixa ca si matematica sau fizica ci inca e in dezvoltare si continua schimbare asa ca nu vad ceva rau in a incerca sa reinventezi ceva in acest domeniu...