Hello.

Pina si Ken ne-a zis, vom merge cu totii spre .NET, n-am probleme cu asta. Dar concret a facut cineva? Si daca da, cum?

Sa fiu concis, sa lasam acum discutiile despre client-server si VFP cu SQL Server, acolo e logic si de la sine inteles. Ma refer la aplicatiile "oldies" din alea cu .dbf si facute cu chiar cu VFP 8. Se pune practic problema sa fie migrata aplicatia in .NET. Folosim MSDE in loc de dbf-uri, dar si asta trebuie bagat in kitul de instalare, cu tot cu ce are nevoie si e de la M$ dar si bazele de date si procedurile stocate scrise de noi, pe astea cum le generezi in kitul de instalare? Trebuie sa mearga struna si sa trimiti kitul la 500 de insi, si e office-based application, local network si atit, nu e pentru web, nu e pentru ASP.NET, e pentru c# sau vb.net. Cum vine toata treaba asta? Merge? Se poate? Hai sa o mai spun si altfel: nu migrez o aplicatie fat client si undeva serverul sql e tot ala, migrez cu totul de la o aplicatie cu dbf la o aplicatie care trebuie sa puna pe masina de lucru si un MSDE direct din kitul de instalare.

Va rog frumos si scuze ca am fost expeditiv si ca revin aici dupa o perioada de indiferenta.

Bogdan, mi-ai stricat surpriza :(

Pregatesc un portal sub Profox, destinat special acestui domeniu: .NET pentru programatorii VFP. Adresa o sa fie www.profox.ro/net (nu e functionala inca, dar o sa fie). Destinatia acestui portal este strict legata de denumire: cum programez in .NET avand VFP ca backround? :)

E dificil. Textbox-urile sunt toate de tip character - trebuie sa faci parsingul ad labam....

cum am si spus .. din pct de vedere al datelor mai tot ce tine de operarea de date se face mai greu.. cel putin pana inveti schema si prinzi ceva indeletnicire.
insa o aplicatie .NET ofera multe alte facilitati nelegate de date, si aici cred ca se poate scrie o compunere destul de lunga.
nu spun ca VFP e rau .. in nici un caz.. ci doar ca ptr o aplicatie care se doreste sa creasca la nivel enterprise  as optata totusi pentru .NET (sau altii mai curajosi chiar Java).
insa pentru clientii de aplicatii mici si mijlocii merge foarte bine VFP ca front-end..si baze de date dbf (ptr cei mici) si/sau un server light (ptr cei mijlocii) ca back-end.
La urma urmei si .NET-ul e o tehnologie si un framework pe care n-au reusit s-o construiasca bine din prima.. si va suferi in timp foarte multe modificari.. (framework ajuns acum la versiune 2.0).
Iar M$ dezvaluie din culise noi tehnologii cu care vor incerca sa "revolutioneze" procesul de dezvoltare al software-ului.

Ce-o sa fie..  o sa vedem.

Si eu facut programe in VFP foarte mut timp. Si din acest considerent n-as da cu piciorul la aceasta tehnologie care are un timp de invatare foarte scurt, a fost si cred ca mai este foarte populara si are facilitati puternice.
Dar pe de alta parte trebuie sa luam parte si la procesul "de asimilare" a altor tehnologii.
Personal am fost implicat si oarecum "obligat" sa invat tot felul de limbaje de programare si bineinteles ca nu am spus NU dar nici nu sunt expert in toate. Insa acest lucru m-a obisnuit cu invatarea si adaptarea la noi limbaje si tehnologii.

Asa ca .. nu vreau sa ofensez pe nimeni.. am tot respectul pentru VFP si ptr cei care lucreaza in acest limbaj de programare.

Cu stima,
Claudiu Farcas

Ei aici gresesc unii manageri de proiect, se iau dupa niste sloganuri de maketing: .NET cu C# suna frumos nu ?
Dar nu se pune in balanta ce inseamna portarea si cate lucruri bune se pierd prin renuntarea la VFP.

Chiar inventatorul C# recunoaste ca la date VFP e mai tare si ar vrea sa se mai inspire:

Regarding C# and FoxPro, Hejlsberg told eWEEK: "FoxPro comes at it from a different angle. They have their own run-time infrastructure and they are not hosted on .Net the same way as the other languages are. So that's the ball they have to chase. C# is already on what we think is the right run-time infrastructure but is lacking the capabilities of deeper data integration. So that's where we're looking."

http://www.devsource.com/article2/0,1895,1854290,00.asp

aplicatii oldies in vfp8 ? atunci how about aplicatii pe vfp6 pe sql7 sau app-uri in fox2.6 !!!

am si eu o intrebare care daca are raspuns face ca anumite app-uri in fox 2.6 sa sara direct in era  .NET  .

SE POT CULEGE, PRELUCRA DATE , DIN FOX 2.6 PE FORMAT XML PE UN .NET ( exemplu raportari de stocuri de la depozit aflat la distanta ) ?[EMO]AngelSmall.gif[/EMO]

LiviuShiva wrote Astept deschiderea sesiunii de .NET unde sa ne impartasim din experienta acumultata si modul in care am rezolvat problemele aparute privind din prisma noastra, a celor care venim dinspre VFP.

Veste buna, s-a deschis Forumul de .NET. Sa ne intalnim acolo. ;)
http://www.profox.ro/netforvfp

Eu sunt mai batrin (53 ani) si am ramas anchilozat la FoxPro DOS, dar lucrez cu VFP 9 pentru interogarile SQL. Dincolo de obisnuinta, un alt motiv pentru care am preferat sa generez pina si rapoarte prin cod a fost faptul ca ma asteptam ca va veni vremea cind trebuie sa migrez aplicatiile spre o alta platforma (ma asteptam ca Fox-ul va avea soarta Cobol-ului la care a renuntat Microsoft). Cam de 5 ani tot cochetez cu ideea de a migra cod FoxPro la C#. Sa faci aplicatiile FoxPro sa lucreze cu Baza de date SQL Server este o treaba destul de usoara daca te limitezi la View (prin ODBC), dar merge foarte prost (foarte lent si cu apar erori erori).

Exista firme care se lauda ca au facut interpretoare pentru migrare FoxPro la C# si SQL Server. Iata un exemplu: http://www.diaspark.com/migration/foxprotodotnet.htm

Am facut si eu un interpretor pentru cod FoxPro la SQL Trasact. Circa 60 ... 70% din migrare o face, dar iese un cod neoptimizat, lent, care mai trebuie periat pina ajungi la o procedura stocata operationala.

Am incercat migrare si pe RentACoder: http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=682859 cu niste indieni. Am platit 100$ de test si a aparut o alta problema pentru mine, tehnologia folosita de programatorul lor era sofisticata (pentru mine), greu de intretinut si depanat ulterior.

In urma cu 2 ani a inceput sa ma ingrijoreze aderarea la UE si m-am apucat de SAP Business One (cu SQL Server 2005). Am inceput sa lucrez in C# sa fac Add-Ons (asta la 51 de ani, asa ca nu va speriati de C#). Acum 95% din timp lucrez singur in C#, din ce in ce mai rar sunt probleme care ma depasesc (am insistat pentru ca am vazut pe Forum ca unii tineri se sperie de C#). Acum rapoartele le fac in Excel si Word (atit in FoxPro, cit si-n C#). Am realizat niste controale AxelSAControls in C# pentru interfata stil SAP B1. M-a ajutat la inceput un

programator cam capiat, un student super si fiica mea Irina STANCA. Am fost chiar invitati la SAP Walldorf in Germania (unde lucreaza 8.000 oameni) si am discutat cu arhitectii SAP B1. Dupa ce am cheltuit direct aproape 5.000 euro si am lucrat eu mai mult de jumatate din timp la aceste controale au iesit niste controale profesionale: http://www.axelsoft.info/site/axelSA.htm, http://www.axelsoft.eu (sunt chiar de vinzare, 200 euro).

Am discutat si cu Grig problema migrarii din Foxpro in .net si, din pacate, suntem de aceeasi parere - aplicatiile trebuie regindite (rescrise). Grig spune ca migrarea din FoxPro catre .net are o limita de virsta (50 de ani). De acord, dar asta cind esti un programator independent, dar cind ai o firma care nu va muri o data cu tine virsta nu mai conteaza. Eu am doua fete, cea mare studenta la ASE-Cibernetica care la 2O ani a lucrat 3 luni in SUA cu SAP B1, iar acum este platita in Romania cu 20 euro / ora (implementare si Add-Ons in C# pentru SAP B1).

Pina acum am reusit sa migrez circa 38.000 linii de cod si ma intereseaza foarte tare acesta problema. M-am cam impotmolit si de aceea cochetez cu ideea de a face o interfata SAP B1 aplicatiilor in FoxPro pe care le avem.

Ion STANCA