.NET-es adatbáziskezelés
2006-03-02T14:48:03+01:00
2006-10-31T18:06:39+01:00
2022-07-26T13:51:19+02:00
  • Na jó, ezt ők állították .
    Részben viszont van benne igaszság. Viszont az tény, hogy erősen kötődik még mindig a Win32-höz.

    De érdemes számolni majd a WPF-re való átálással is. Majd megnézem, hogy melyik lesz az egyszerűbb, mondjuk egy a kezdetektől (Win32) fejlődő nagy üzleti alkalmazásnál az átállás. A VCL-en meg végig lehet csúsztatni a projektet akár a WPF-ig is, a jelenlegi álláspont szerint.

    Viszont tény, hogy újat mondjuk én is szívesebben kezdenék VCL nélkül, de addig nem, amíg nem alakul ki a végleges felállás, ami remélem a WinFX-el bekövetkezik.
    Mutasd a teljes hozzászólást!
  • Ez win32 alatt alapjában véve nem volt baj. De az is igaz hogy a win32 API úgy igazán nem nagyon változott csak bővült (szemben Pl. a linux-szal ahogy egy gtk1->gtk2 átállás finoman szólva nem egyszerű, Pl. a lazarusnak máig nem sikerült normális gtk2-es lcl-t összehoznia). Most viszont a .NET alatt a win32-höz visszanyúlogató VCL.NET finoman szólva nem a legegészségesebb ötlet.
    Mutasd a teljes hozzászólást!
  • Tehát a VCL-re lehet úgy tekinteni, mint védőfalra, ami megvéd a microsoft folyamatosan változó api-jaitól.


    Azért ez így ebben a formában nem igaz. A VCL is azzal kezdi, hogy szépen portolja magába a WINAPI függvényeket.
    Mutasd a teljes hozzászólást!
  • Jó nagyon a VS, ez tény, de nem mindenben a legjobb! De ezt nem is lehet elvárni senkitől sem. Nyilván mindig lesznek feladatok, amiket egyszerűbb VS-ben megcsinálni és fordítva. Ezért is, én inkább kimaradok még egyenlőre ebből a VS Istenesítésből. De ugyanakor nem magasztolom fel a Delphit se felé. Én legalább minden nyelvnek és fejlesztőeszköznek képes vagyok meglátni a maga szépségét (még a VB-nek is ).
    Mutasd a teljes hozzászólást!
  • Azért a .NET-es tárolt eljárásoknak is van árnyoldala, Pl. sebességben állítólag jóval lassabbak mint a hagyományos tárolt eljárások. Ugyanakkor nekem már az nagy élmény hogy egyrészt a MS-SQL tárolt eljárásainak nyelve egy elég nagy felüdülés a firebird után, másrészt hogy ott a tárolt eljárás debuggolási lehetőség (meg az egész management) az IDE-ben.

    Ami viszont nem igazán tetszik az a dataset-ek sebessége. Elég lusta egy jószágok sajnos, és nem is annyira a feltöltésük a tetű hanem a kezelésük. Pl. ha egy gridhez hozzákötsz egy dataset-et és beleteszel 20 000 sort akkor vagy 20 másodpercet kell várnod mire életre kel a dolog. A másik árnyoldala a dolognak hogy az egész memóriában kavar. Nem tudom a M$ miért nem tudott összedobni egy DBF-szerű mini "adatbáziskezelőt" ami fájlokkal manipulálna és gyorsabban tudna mozogni mint ez a szerencsétleg datatable a datasetben... Persze, tudom a megoldás az hogy ne tegyünk 20 000 sort egy táblába, de bizony sajnos néha kell...
    Mutasd a teljes hozzászólást!
  • de a win32 alapú Delphi IDE-k viccesek


    ... és felháborító módon bugosak! Pl. Builder 6.0 alatt lehetetlen volt használni az Action komponenseket, mert szinte minden változásnál megkeveredett magával.

    Ráadásul itt használhatom a C# nyelvet, nem kell a Pascal-lal szenvednem...


    Mind a Pascal, mind pedig a C/C++ a jó 20+ évvel ezelőtti időkben lettek fejlesztve. Magukon hordoznak egy csomó ballasztot (Pascal: elkülönített deklarációk, interface, stb; C/C++: headerek), amire azért volt szükség, mert az akkori gépek nem voltak képesek egy az egyben megemészteni a forrást "on-the-fly", és ezért el kellett valhogy különíteni azt a részt, amin keresztül a programmodulok hivatkozhattak egymásra. Erre egy mai átlag munkaállomás teljesítményét nézve a világon semmi szükség, az egész kódot értelmezni lehet már a beíráskor. A C# ennek fényében lett megírva, és ennek köszönhető az egyszerűsített szintaxis, amit mindenki nagyon szeret.

    Jólvan, ne flémeljek már állandóan. Az adatbázis-kezelésben (számomra) még mindig a legfájdalmasabb pont az SQL nyelv. Arra találták ki, hogy (száz éve) az egyszeri adminisztrátor is megközelítőleg angol nyelven le tudja kérdezni az adatokat. Eredetileg egész értelmesen olvasható volt egy query. Ahogy nőttek az igények, úgy kerültek bele a nyelvbe az összetettebb dolgok (iterációk, deklarációk, stb), és ettől a perctől kezdve az SQL nyelvjárás már messze került a fájától. Szvsz egy szedett-vedett logikátlan halmaz, ami tele van speciális esetekkel, amit minden jobb érzésű rendszer messze elkerül.

    DE! Végre lehet C#-ban írni a tárolt eljárásokat (SQL Server 2005)! Most kezdem magam beleásni a témába, és egy kánaán az egész! Végre olyan nyelven és logikával írhatom az adatelérés kódját, mint világ életemben tettem a programjaimnál. Ráadásul vére vannak osztályaim, amikből származtathatok -> polimorf query-k, normális hibakezelés, saját adattípusok, a teljes .NET osztálykönyvtár (persze a megfelelő trust level alatt), minden, ami csak valaha kellhet, és mindez a szerver oldalon! Manapság már a legtöbb szolgáltatónál SQL Server 2005 fut, szóval megéri mindenkinek beleásni magát a témába, mert messze-messze-messze értelmesebb így a munka, mint SQL-ben, ahol egy nyúlfarknyi változtatás hatására (egy nagy rendszernél) harmincmillió tárolt eljárást kell szétkopipésztelni, aztán ha egy kimaradt, szívhatja a fogát a Tisztelt Fejlesztő.
    Mutasd a teljes hozzászólást!
  • Viszont bizonyos szolgáltatásokban többet nyújt, ami viszont nem a VS érdeme, hanem a .NET 2.0 érdeme.


    Azért a VS-nek is van érdeme bőven. Nekem spec. nagyon tetszik, hogy 1 megveszekedett sor beírása nélkül el tudom érni az adatbázisom adatait, sima query-kel vagy tárolt eljárásokkal a típusos adathalmazokon keresztül. A VS magától megír minden szükséges kódot, csak kattintgatni kell.
    Mutasd a teljes hozzászólást!
  • Ez igaz is meg nem is. A Delphi alapvetően nem volt rossz a maga idejében, de ez az idő úgy 1995 tájékán volt. Aztán még sokáig egész jó platformnak számított, de mára mind a java mind a .NET messze túlnőtt rajta. Én VCL-ről majd CLX-ről tértem át .NET 2.0-ra, de nem bántam meg. Ráadásul itt használhatom a C# nyelvet, nem kell a Pascal-lal szenvednem...

    Ami az IDE-t illeti, a D8 óta már elviselhető /csak lassú volt, a d2k6 óta állítólag gyorsabb, de mostanság úgy vagyok vele hogy csak ezért nem teszek fel 1.1-es .NET-et a 2.0 mellé/, de a win32 alapú Delphi IDE-k viccesek - röhely hogy a Borland a D7-ig sem tudott egy olyan egyszerű dolgot megcsinálni a fejlesztőeszközébe mint egy rohadt zárójel kiemelés, pedig ezt akkor már egy jobb open-source text editor is tudta...
    Mutasd a teljes hozzászólást!
  • Persze, ezért fogalmazott így Marco Cantú is, hogy aki eddig a Delphit használta: "Mi ez a nagy hűhó a .NET körül?" Ez részben nagyon is igaz volt. Aki eddig Win32 Delphiben programozott, annak bizony a Borland kezére adta azokat a felületeket, melyekkel játszi könnyedséggel építhetnek gyors és robosztus alkalmazásokat. Én is használom mindkettőt, VS C# és Delphi, és bizony mindig még mindig nehezmre esik átállni sima .NET WinForms-ra, ami bár hasonló, de elviekben mégis más. Ugye már mindent tudok, hogy a VCL-ben mi hol van, hogy kell használni, stb. és nehéz befogadni most egy másik szervezettől egy teljesen másfajta megközelítést. Többek között ennek a kiküszöbölésére született meg az ötlet, nem csak Win32->.NET portolási indokokból, hanem a jövőre nézve is: VCL for Win32, VCL for .NET 1.x, VCL for .NET 2.0, VCL for WPF.

    Míg a VS használók írhatják át az egész mindenséget, ahogy változtatja a microsoft a platformokat, addig a borland a vcl használatával ezt ha nem is 100%-an, de elég hatékonyan áthidalja. Tehát a VCL-re lehet úgy tekinteni, mint védőfalra, ami megvéd a microsoft folyamatosan változó api-jaitól. A Delphi eleve, mint az egyik legnagyobb adatbáziskezelő alkalmazások fejlesztési eszköze robbant be a piacra, tehát azért ezt se feledd, hogy a Borland minden erővel azon volt, hogy leegyszerűsítse a különböző forrásból származó adatokhoz történő hozzáférést.

    Megnéztem én is a VS adatbáziskezelő részét, annyira nem gáz, de nem is az a nagyon f..a egyszerű, mint a konurennsé . Viszont bizonyos szolgáltatásokban többet nyújt, ami viszont nem a VS érdeme, hanem a .NET 2.0 érdeme. Ugyanezek elérhetőek lesznek D Highlander és D Vista-ban is:
    "A microsoft platformjai számunkra nem több, mint stratégia platformok"

    Viszont tény, hogy aki eddig VS-ben fejlesztett, vagy esetleg C++ Builder-ben, azzal most madarat lehet fogatni a VS láttán. Aki már legalább 10 éve foglalkozik Pascal és Delphivel, annak sokkal kevésbé jelentenek újat ezek a dolgok, bár van mit tanulni ettől függetlenül .

    Jó tanulást!
    Mutasd a teljes hozzászólást!
  • akkor New Data Source-menüt keresdd és ott a wizzard segit beállítani a Connenction Stringet, amivel az SQL adatbázist eléri a provider.

    Ettől kezdve a designerekkel/kódból tudsz mindenféle query-t, akármit csinééni a VS-ben.
    Mutasd a teljes hozzászólást!
  • sztem most neked 1ik sem, hanem:

    innen:Search results - Microsoft Download Center
    a .NET Framework Version 2.0 Redistributable Package (x86)-et tedd fel ha még nem tetted...
    Mutasd a teljes hozzászólást!
  • fent van az ms sql is ezzel szeretnék kapcsolatba lépni
    Mutasd a teljes hozzászólást!
  • Nem kell semmi. Illetve .Net framework 2.0 legyen a gépeden, de a többi "készen van",
    lehet használni.

    Igaz ha ADO.NET-et akarsz akkor gondolom van vmi adatbáziskezelő is a gépeden, MS SQL, Oracle, ....

    MSDN ben az ADO.NET ről külön fejezet van, érdemes átfutni.
    Mutasd a teljes hozzászólást!
  • Ezek közül melyik kell?

    ado.net
    Mutasd a teljes hozzászólást!
  • Sziasztok !

    Előre is bocsi ha valami hatalmas hülyeséget kérdezek.
    Le kell valamit töltenem a Visual C# Express-hez ha a ADO.NET-et szeretnék használni?
    Szoval ADO QUERY meg ilyenek?
    Egyáltalán van ilyen .NET-ben?
    Mutasd a teljes hozzászólást!
  • Magyar rögvalóság
    (ld. témainditó hozzászólás)
    Mutasd a teljes hozzászólást!
  • Valójában annyi is elég ha a select mondatba feltételt teszel. Azaz a select mondatod úgy néz ki Pl. hogy select * from proba where id=@id. Ekkor a fill parancs kap egy ID paramétert is a datatable mellé.
    Mutasd a teljes hozzászólást!
  • A TableAdapter-hez a sémában lehet query-t adni, aminek hatására létrejönnek rajta FillBy metódusok, azokat lehet a paramétereket meghívni.
    Mutasd a teljes hozzászólást!
  • Én is Delphiben fejlesztettem eddig. Most próbálkozom a C#-val. Néztem ezt a tableadaptert, de nem látom, hogyan tudom elérni a selectcommand.commandtext-et. Vagy a paramétereknek értéket adni benne. Szeretném futás időben értéket adni a paraméternek, de nem tudom elérni. Lehet ilyet egyáltalán valahogy?
    Mutasd a teljes hozzászólást!
  • "The complete, updated 101 Samples were posted 2 weeks ago. It did take a few days longer than the "week" I expected due to the MSDN guys being tied up with [covered by NS: this and that which] were deemed priorities by others. All samples have been tested with the RTM versions of Visual Studio 2005 and SQL Server 2005. Any download of Adventure Works since the RTM releases on 7 November 2005, should work with the samples."

    Ezek után már csak egy pontosításra volt szükségem (mivel minden felvetett kérdésre választ adott ezzel), hogy:
    "The "complete, updated 101 Samples ... posted 2 weeks ago" are at the same place as the incorrect previous ones?
    That is on the http://msdn.microsoft.com/vstudio/downloads/101samples/default.aspx? (I was not able to find anything other than that even by extensive external search.)"
    Mutasd a teljes hozzászólást!
  • Levelem Johnhoz szó szerint a következő volt:

    John, were the 101 samples still NOT made available?

    The people originally complaining about that are complaining again that the latest "about a week" promise has not been met.

    There is also a question from them: "Why should we wait for new samples for the new database, when it would be only necessary find the old database for the old samples?"
    Mutasd a teljes hozzászólást!
  • Tiosztelt Nacsa Úr!

    Egyébként nem értem, hogy miért kell várni új példákra az új adatbázishoz, mikor a meglévő példákhoz csak elő kéne kotorni és letölthetővé tenni a régi adatbázist?
    Rosszul látom?

    Ez is szerepel a kérdésében?

    Lehet, hogy sosem volt ilyen adatbázis?
    Mutasd a teljes hozzászólást!
  • köszönöm az anyagokat amiket ajánlott, de nem hiszem, hogy élni fogok ezekkel a lehetőségekkel.


    A csatolt kompiláció egyfajta checklist-ként való használatát (vagyis kipipálandó az elsajátítandókat) ugyanakkor komolyan figyelmébe ajánlanám.

    Üdv
    Nacsa Sándor
    Mutasd a teljes hozzászólást!
  • A már begyakorlott Delphivel való összehasonlítás, a produktivitás szempontjából, szerintem csak ezután történhet érdemben (és még nem is azonnal).


    Ez tiszta sor, egyet is értek Önnel. Én nem is akartam még így a kezdet kezdetén összehasonlítani a két fejlesztőeszközt, hiszen még nincsenek meg hozzá a kellő ismereteim. Én csupán az átállással kapcsolatban szóltam hozzá a témához. Természetesen ez eltart két-három hónapig, az pedig hogy úgy megismerjük, mint azt a fejlesztőeszközt amivel évekig dolgoztunk szintén évekbe fog telni szerintem... Mindenestre köszönöm az anyagokat amiket ajánlott, de nem hiszem, hogy élni fogok ezekkel a lehetőségekkel. Beszereztem már pár könyvet a témában, melyekből kellően meg tudom tanulni az adatbáziskezelést, s egyéb mókákat, csak
    ugye idő-idő-idő...

    További jó munkát!
    Üdvözlet!
    Mutasd a teljes hozzászólást!
  • Tisztelt Riha !

    John Wingfield-et tudom csak erről megkérdezni, amit most meg is tettem.

    Üdv
    Nacsa Sándor
    Mutasd a teljes hozzászólást!
  • Tisztelt ppál és ptms !

    A három napos hétvégén családomtól lecsípett időben utánanéztem az Önök, alapelsajátítási igényeit kielégítő dolgoknak:
    -- az MS Learningtől megjelentek új e-learning workshop-ok "core" és "advanced" kategóriákban, amik általam kompilált összegzését csatolom
    -- a "The Difference is obvious" kampányszlogen keretében pedig VB6, klasszikus ASP és VS03 fejlesztők VS05-re képzését segítő anyagok sora.

    Az előbbiek fizetősek, míg az utóbbiak díjmentesek. Mindkettő persze angolul van.

    Viszont a VC#05 és a VB05 elsajátításához -- legalább részben kötődve azokhoz az alkalmazási kategóriákhoz, amikkel a fenti anyagok foglalkoznak -- van most egy 20 ill. 30%-os kedvezményes akció, mégpedig magyar nyelvű könyvekből.

    Visszatérve a "core" és "advanced" e-learning workshopokra:
    -- a "core data access + core Windows client"-hez (ami a Delphi-ről áttérőknek a közvetlenül releváns) 1-3 hónapnyi VS05 teljes idejű fejlesztő gyakorlat szükséges
    -- ezt a gyakorlatot szerintem legalább valamilyen pilot fejlesztés (akár a megfelelő Express változatot használva, ami most már mindvégig díjmentes) és annak kapcsán egy adott 2005-ös nyelv (VB05 vagy VC#05) legalább a fenti magyar nyelvű könyvek alapján való elsajátítása jelenti
    -- ezután (ha valaki tud angolul ilyen e-learning workshop-okat használni) 16+18 órás időtartamban lehet elvégezni hozzávetőleg a "core data access + core Windows client" workshop-okat, és ez $544-be kerül.

    A már begyakorlott Delphivel való összehasonlítás, a produktivitás szempontjából, szerintem csak ezután történhet érdemben (és még nem is azonnal).

    Emellett mindenkinek ajánlom a "core data access + core Windows client" workshop-ok megismerését a csatolt kompilált dokumentum alapján, mivel ebből rögtön áttekintést is kapnak arról, hogy miket is kellene elsajátítani.

    Ennek kapcsán arra is felhívnám a figyelmet, hogy itt adathozzáférés szempontjából csak a "typed dataset"-en keresztüli hozzáférésről esik szó, illetve az ezen keresztüli űrlap adatkötésről (és nem esik szó az objektumokon vagy webszolgáltatásokon keresztüliekről -- egyébként az objektumokon keresztüliekről még az "advanced" workshopoknál sem).

    Üdv
    Nacsa Sándor
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Az elején tényleg sokkal lassabban megy a fejlesztés az új eszközön, de ez természetes dolog! A fizetős munkáknál viszont nincs idő napokig szenvedni olyan dolgokon, ami a "régi" eszközben gyorsan megy!
    Azért a .NET és a C# nincs elfelejtve! Ha megint lesz egy kis "nyugalom", (ami remélem nem azt jelenti, hogy éhen kell halnunk, mert nincs fizetős munkám ), akkor megint jön a C#! Ilyenkor van idő a problémákon rágódni, és kisérletezni, de határidős munkáknál ezt az ember nem engedheti meg magának!
    Mutasd a teljes hozzászólást!
  • Na jó, talán egy kicsit túlóztam... Viszont rengeteg időm elment az elején azzal, hogy például egy Gridben megjelenítsek több táblából összegyűjtött, kapcsolódó adatokat... Delphiben ezzel már nem nagyon kell szenvednem, kapásból tudom hogyan álljak neki.
    Mutasd a teljes hozzászólást!
  • Új IDE-vel és teljesen új technológiával ez az elején szerintem természetes. Az aranykalapács már nem használható .NET/VS.NET alatt, bizony újra meg kell találni.

    (Én spec Eclipse-ről jöttem, és bizony túrtam egy ideig az msdn-t és a tutorialokat amíg összeállt a kép.)
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd