SQL szerver használat Accessben
2007-05-13T08:49:07+02:00
2009-09-08T08:33:35+02:00
2022-07-25T11:11:16+02:00
  • Az Access nem zsákutca szerintem.

    Aki kitalálta, annak nagy fantáziája volt.

    Persze arra kell használni amire való. Az MS sablonjai felejthetőek.

    Kisebb, kiegészítő dolgokat viszont nagyon kényelmesen lehet vele csinálni.
    Mutasd a teljes hozzászólást!
  • Hali!

    Ha konkrét kérdésed van, azt a Tudástárban tedd fel. Ha pedig megoldatnád valakivel a problémádat (ellenértékért/-szolgáltatásért cserébe), akkor az Állás-rovat a megfelelő.

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

    Légyszi segítsetek!
    Van egy feladatom: Adatbázist kell létrehoznom, melyben az adatokat adatelérési lapon keresztül, és a hozzá kapcsolódó Apache Webserver használatával szeretném bevinni.

    A lényeg: Access 2003-mat kell használnom.

    Kérdés: Meg lehet valósítani a feladatot Access 2003-ban?

    Előre is köszönöm.
    Mutasd a teljes hozzászólást!
  • Én őszintén szólva a MySQL-t nem igazán használom szívesen semmire, és ugyanez igaz az accessre is, mdb-vel vagy anélkül. Ha fejleszteni akarsz akkor használj komoly eszközöket ami fejlesztőeszköznél .NET (szigorúan C#, semmi VB) vagy Delphi vagy Java vagy C++ (de ez utóbbit nem ügyvitelre), adatbáziskezelőnél pedig MS-SQL, Firebird, Postgresql, Oracle, DB2, esetleg SyBase.
    Mutasd a teljes hozzászólást!
  • Kis probléma: az Access ADP csak MSSQL-lel közösködik.
    Mutasd a teljes hozzászólást!
  • Nemnem!!! N em akartam flamet, de ha józan paraszti ésszel gondolkodik a srác, akkor nem kell csak egyfele nézni. Nem szabad szemellenzősem erőből (és sok, sok pénzből) megoldani a problémákat. Szabad mást is megnézni, ielőtt dönt és én csak JAVASOLTAM neki, hogy tegyen egy próbát MySql-el. Én is végigjátszottam ezt a vonalat és sok-sok mindent kipróbáltam. A véleményem az, hogy amennyiben egy egyszerűbb adatbázis szerkezetről van szó, akkor nem szükséges neki MSSQL. Annak idfején én is sokat kipróbáltam (MySql 4.x, 5.x, FireBird, MSSQL, PostgreSql, Oracle10, Mdb, stb. ) és ahhoz az adatszerkezethez, amit nekem kellett használnom, a leggyorsabb és a legegyszerűbb megoldás a MySql volt. Ha nincsenek bonyolult lekérdezések, meg cascadolt frissítések, meg tárolt eljárás hegyek, akkor a MySql lehet egy job megoldás.

    Csak ötlet volt, nem kötelező és semmiképpen nem flame... Választhat sok megoldási módszerből és eszközből. Ezért szeretem (és választom sok megoldásra) a linuxot. Viszont sokszor (egyre többször) kell MS terméket használnom. Na mind1, ez már egy másik topik
    Mutasd a teljes hozzászólást!
  • Flém, de MySQL vs MSSQL 2005 ... ööö ... jaj
    Mutasd a teljes hozzászólást!
  • Vagy postrgresql-t, mert bizonyos esetekben a mysql fizetős.
    Mutasd a teljes hozzászólást!
  • Van még egy variáció: MSSQL helyett egy MySql 5.x-t az Access alá rakni próbaként. Amennyiben nincs szükség az MSSQL tudására, akkor ezzel is elég jól el lehet boldogulni. Egy próbát megér.
    Mutasd a teljes hozzászólást!
  • Alább írtad, hogy 30 egynéhány ügyfelet szolgál ki a rendszer. Itt meg kell gondolni, hogy van-e rá cash, ezért írtam a CAL árakról. Az SQL Express 20 csatlakozás fölött megadja magát. Minimum kell ide egy WG, plusz akkor már egy 2K3, hogy az egész WA is ki legyen szolgálva. Ehhez, ha SBS van, kapsz 5 CAL-t. A 30-hoz még kell 25, ami 5-ösével ennyi pénz:

    MS OEM WIN SBS CAL 2003 5 DEV ENG CAL T74-01094 95 672 Ft +ÁFA /5 user


    Van 20-as pakk is, az kicsit több, mint 300 ropi.

    Tehát a 25 hozzáférés nagyjából 400 000 Ft, ami nem kis pénz.

    Ezt úgy lehet(ne) megkerülni, hogy bevezetsz egy middle tier szolgáltatást, és a kliensek ahhoz kapcsolódnak, így nem eszi a licence-t a dolog. Ennek kivitelezése viszont több éves gyakorlatot kíván, nem lehet csak úgy beleugrani mindenféle tapasztalat nélkül. Ilyeneket kell átnézni, mint Enterprise Library, kell valami Smart Client/Web Client Factory, Service Factory, satöbbi.

    Egyébként ez utóbbi dolognak simi.2 kolléga a mestere, Őt kéne meginterjúvolni, hogy merre meg meddig. Én csak idéntől kezdtem el ezzel komolyabban foglalkozni, és tényleg fel kell kötni a gatyát.
    Mutasd a teljes hozzászólást!
  • A 20 évvel ezelőtti gépek memóriájába a VS indító ikonja sem fért volna be
    Mutasd a teljes hozzászólást!
  • Nekem tetszika stratégiád. Sok sikert, és várom a tapasztalatokat.
    Mutasd a teljes hozzászólást!
  • Ha 20 évvel ezelőtt már lett volna VS2005 és az SQL2005, biztosan kihagyom a dBaseIII-at, a Clippert, az MSC-t, a VB6-ot, az SQL 7.0-2000-et, az Access97-2003-t, meg a VB.NET 2003-at.

    Szval a zsákutcából kell valahogy kitolatni.
    Mutasd a teljes hozzászólást!
  • Sztem az a jó stratégia, hogy az Accessben írt új alkalmazásokat már express SQL szerver-re írom.

    Innentől kezdve az adatbázis motor már nem kérdés, mert ha adatbázis oldalon teljesítményhiány lenne, skálázással megoldható.

    A VS-re való átállás úgyis időben elhúzódó folyamat, de egy-egy alkalmazás kritikus részeit részben is át lehet írni, függetlenül attól, hogy az adatbázis motor átállt-e már SQL szerverre, vagy maradt Jet. Az új alkalmazásoknál az Access és a VS marad alternatíva, a körülmények függvényében.

    A meglévő kisebb alkalmazások maradnak Access-Jet alatt, a növekvő alkalmazásoknál meg vagy az SQL szerver, vagy a VS részek, vagy az SQL szerver és VS együttese a jó megoldás.



    Mutasd a teljes hozzászólást!
  • Egyszerűbb 4 alatt mindent Visual Studióval csinálni. Az access egy zsákutca, az eredeti koncepciója az volt hogy majd Gipsz Jakabka megcsinálja magának az ügyviteli rendszerét és nem kell programozót fizetnie. Ezért aztán eléggé le van egyszerűsítve, de ennek egyrészt ára van, másrészt a programozásban a fejlesztőeszköz ismerete a legkevesebb.
    Mutasd a teljes hozzászólást!
  • Most a kis projectben vagy . Kinőtted. Lehet, hogy elég lenne a közepes, de lehet, hogy nem lenne túlzás a nagy. Ahogy ezt Te írtad az elején.
    Most jelentkeznek problémák. Választhatsz egy gyorsabb, de nem biztos, hogy végleges megoldást és egy lassúbb, de véglegest.

    A gyorsabb tartalmaz számos olyan lépést, amit akkor is meg kell tenned, ha a végleges megoldás a végső döntésed.

    A táblákat, ha még nincsenek ott, át kell tenni, a lekérdezéseket nagyrészt át kell írni az sqlszerverre. Az sqlszerveren az adatbázist be kell szabályozni, esetleg triggereket írni.

    Ezután jöhet a felhasználói felület kérdése, és annak a mérlegelése, hogy keresel-e egy esetleg csak átmeneti megoldást és ettől még befektetsz magadba, vagy befektetsz magadba és dolgozol egy végleges megoldáson, de a problémák addig jégre kerülnek.

    Számomra a közepes elég volt, ezért is könnyű volt a döntés.

    Nem akarlak rábeszélni a példám követésére, de mielőtt végleg elveted, szerintem megér 2-3 nap játékot. Ez is befektetés.
    Mutasd a teljes hozzászólást!
  • Habár tényleg van szubjektív oldala is, de szerintem az objektív oldal a lényeg. Skálázott feladathoz, skálázott eszközök: mind az adatbázis, mind a fejlesztőeszköz, mind a fejlesztő skálázott.
    1. Kis project, kevés felhasználó, kevés idő, kis befektetés, kis költségvetés = Access és Jet
    2. Közepes project, ..... = Access projekt - SQL szerver
    3. Nagy project,.... = VS (C++,VB,C#)- SQL szerver
    4. Multi project, ... = SAP - SQL szerver

    Tehát a Te döntésed, hogy hova "skálázod" be magad.
    A tanulás itt befektetés, hogy megtérül-e, azt persze senki nem garantálja, de ha nem tanulsz, nincs minek megtérülni!
    Ráadásul mindig készen kell állni a "nagy" lehetőségre



    Mutasd a teljes hozzászólást!
  • Ahogy az utóbbi hozzászólásokat olvasom, lehetséges, hogy pusztán lustasági okok miatt, érdemes az Accessen belül maradni, a projektre áttéréssel. különösen akkor, ha a felhasználók számának drasztikus növekedése nem várható. Talán 2-3 napot érdemes lenne ráfordítanod egy próbára ezen az úton.
    Mutasd a teljes hozzászólást!
  • Őszintén szólva, szerintem a saját vezérlők elkészítésének ideje eltörpül amellett a kulizás mellett, amit a program többi részének a migrálásakor csinálsz. Ha képben van az ember, akkor egy ilyen bonyolultságú dolgot mint pl. többoszlopos listbox 1-2 nap alatt bőven össze lehet hozni. De talán néhány óra is elég. A folyamatos űrlap az már kicsit rázósabb, leginkább amiatt, hogy meg kell oldani az adatkötést is, de az sem lehetetlen (de WPF-ben sokkal könnyebb, mint WinForms-ban).
    Mutasd a teljes hozzászólást!
  • Itt van a 2 változat leírása. A FrontPage csak dísznek van, én is dobtam a fiókba, de az SQL WE és az ISA 2004 nélkülözhetetlen.
    Mutasd a teljes hozzászólást!
  • Egyébként az SBS-hez tényleg csak az SQL 2000-t adják, ami nagyon-nagyon birka a 2005-höz képest. Van viszont SBS R2 Premium kiadás, amihez jár az SQL 2005 Workgroup, mindez néhány tízezressel hosszabb csak. Nagyon megéri, csak egy baj van vele, hogy 5 CAL-t adnak, aztán qrva drága hozzá a többi (ebből jön a bevétel, az első 5-ös csak a beetetés). Jelenleg 100 ropi a + 5 CAL.
    Mutasd a teljes hozzászólást!
  • Hát igen! Az átálláshoz rá kell számolni azt az időt, ami alatt a saját vezérlőidet elkészíted. Egyébként minden egyes projectben jelentős többletidő ráfordítással kell számolni. A Componentsource-on rengeteg vezérlő van, de aranyáron vannak, és nem férnek bele sem a költségvetésbe, sem a programozási stílusba. A gyári vezérlők meg ezek szerint nemigen változtak
    Mutasd a teljes hozzászólást!
  • 4. Cca mennyi tanulási idő kell VB.NET 2005-höz, és milyen könyvet javasoltok (elsősorban adatbázis alkalmazások fejlesztése)

    Ha most vágsz bele és nem holnapra kell készen lennie a dolognak, akkor melegen ajánlom a máj. 24.-ei konferenciát indulásnak. Egyrészt ingyen van, másrészt pont az adatkezelés újításairól van szó. Apró hátrány, hogy valószínűleg nem VB, de a VB6 és a VB.NET között nagyobb a szemléletbeli különbség, mint a VB.NET és a C# között. A másik apró hátrány, hogy ebből csak valamikor az év vége felé közeledve lesz éles rendszer.

    5. Elég sok tételsoros rögzítésem van. Az Accessben erre a folyamatos nézetű segédűrlap egy jó és gyors megoldást szolgált (összes vezérlő használható). Milyen megoldás vált be Nektek VB.NET-ben?

    Sajnálatos módon ez az egyik legsúlyosabb hátrány, amivel szembe kellett néznünk a migrálás környékén. VB.NET-ben nincs olyan, hogy folyamatos űrlap, úgyhogy kézzel kell custom control-t létrehozni. Vagy ha egy sima táblázatos valami elég, akkor arra van többféle grid, de saját elrendezést csinálni minden rekordra az húzós.

    6. A fejlesztési időből sokat elvisz a hibakeresés és javítás. Az Accessben a futó kódot át tudom írni, visszahúzom a mutatót, és újra rá tudok állni a javított sorra. A 2003-nál nem tudtam átírni a kódot runtime. Mi a helyzet 2005-nél?
    Általában a teljes fejlesztési idő uarra az alkalmazásra milyen Accessben és VB.NET-ben?

    Van edit&continue, de tudtommal visszafelé nem lehet lépkedni a végrehajtásban.

    8. Tudom, hogy az SQL szervernél a válaszidők már az adatbázis tervezésekor nagyrészt eldölnek. Az Access-es tábla, index, és integritás tervezési gyakorlattól miben tér el az SQL szerveres?

    Leginkább olyan architekturális eltérés van, hogy míg az Access online adatelérési modellt használ, a VB.NET offline-t. Vagyis az előbbi kurzorszerűséggel lépked a táblákban, és általában mindig a legfrissebb állapotot mutatja, az utóbbi meg előre lehúzza az összes adatot, foglalkozni kell a konkurenciakezeléssel is, de sokkal jobban skálázódik. Magának az adatbázisnak a szervezése nagyjából ugyanaz (PK, index, relációk, stb)

    9. Az Access combobox elég rugalmas, van rágépelési lehetőség. Az eddigi VB verziókba a gyári datacombo, combo, listbox, Datalist elég fapadosnak tűntek. Milyen a VB2005-ös megoldás?

    Egy olyan dolog jut most eszembe, ami nem gyári a VB.NET-ben: a többoszlopos (és/vagy fejléces) list- illetve combobox-ok. De ezeket végülis egy saját rajzolatú vezérlővel meg lehet oldani. Nem túl bonyolult.
    Mutasd a teljes hozzászólást!
  • Én az építkezés híve vagyok, tehát

    Biztosan lesz tapasztalat, biztosan lesz kérdés, és biztosan meg is fogom osztani Veletek...
    Mutasd a teljes hozzászólást!
  • Az ELVI 50-50 pontot köszönjük, gondolom a Riha nevében is beszélhetek. Esetleg, ha van értékelhető tapasztalatod, akkor visszatérhetnél ide, és megoszthatnád a többiekkel.
    Mutasd a teljes hozzászólást!
  • Bocsi, de itt még 1x50 sincs (társalgó).
    Itt csak ilyesmi van, pl.
    vagy esetleg stb..
    Mutasd a teljes hozzászólást!
  • Köszönöm az infókat.
    A téma kettévált, és 2 in 1 lett.
    Az SQL áttérésben Sipeki, a fejlesztő áttérésben Riha tanácsai voltak számomra hasznosak.
    Szerintem itt le is zárhatjuk, majd a részleteket új topicban.
    Van olyan, hogy 2x50?

    Mutasd a teljes hozzászólást!
  • 1. Úgy tudom, hogy a VS expressz verzió csak saját használatú sw fejlesztéshez ad jogot (mondjuk tanulni jó). Mennyi a VB.NET 2005 fejlesztő ára?.


    Rosszul tudod, érdeklődj a Microsoft-nál!

    2. Az SBS 2003-hoz csak a SQL 2000 jár. Ezt a példányt lehet-e upgradelni?


    Rosszul tudod, érdeklődj a Microsoft-nál!
    3. Az MS-nek van-e még fejlesztő támogatási konstrukciója?

    Search for a Support Answer Online
    4. Cca mennyi tanulási idő kell VB.NET 2005-höz, és milyen könyvet javasoltok (elsősorban adatbázis alkalmazások fejlesztése)

    ?
    5. Elég sok tételsoros rögzítésem van. Az Accessben erre a folyamatos nézetű segédűrlap egy jó és gyors megoldást szolgált (összes vezérlő használható). Milyen megoldás vált be Nektek VB.NET-ben?


    DataGridView
    6. A fejlesztési időből sokat elvisz a hibakeresés és javítás. Az Accessben a futó kódot át tudom írni, visszahúzom a mutatót, és újra rá tudok állni a javított sorra. A 2003-nál nem tudtam átírni a kódot runtime. Mi a helyzet 2005-nél?


    Megoldható..
    Általában a teljes fejlesztési idő uarra az alkalmazásra milyen Accessben és VB.NET-ben?


    Próbáld ki..

    7. A VB6-nál CR8.5-öt használtam a listák gyártásához. Azt tudom, hogy a CR a VS része lett. Akkor vezették be a központi CR szervert. Sok változás van?


    Ő a menő..

    8. Tudom, hogy az SQL szervernél a válaszidők már az adatbázis tervezésekor nagyrészt eldölnek. Az Access-es tábla, index, és
    integritás tervezési gyakorlattól miben tér el az SQL szerveres?


    Kezdőkönyv az SQL Server 2005 programozásához (Robert Vieira)

    9. Az Access combobox elég rugalmas, van rágépelési lehetőség. Az eddigi VB verziókba a gyári datacombo, combo, listbox, Datalist elég fapadosnak tűntek. Milyen a VB2005-ös megoldás?


    MSDN - tutorial

    10. Vannak olyan törzstábláim, amiben a rekordszám meghaladja a 64k-t, ami a combo és listboxok max mérete. Ezért kellet készíteni egy textbox alapú vezérlőt, amibe a begépelési sebességnek megfelelő sebességgel fel kell tölteni adatbázisból a neki addig beírt szövegnek megfelelő rekord egy adott mezőtartalmát (LIKE *). A korábbi VB verzióknál elég lassúnak tűnt a LIKE*-os SQL szerveres lekérdezés az accesshez képest. Van erre bevált, gyors megoldás a VB2005-SQL2005-ben?


    MSDN - tutorial

    11. A űrlapok (törzskarbantartók, rögzítések, listamaszkok) gyártása meglehetősen unalmas, egyhangú munka. Ráadásul nagyon körülményes volt a vezérlők felhelyezése, elrendezése, vagy átrendezése a korábbi VB verziókban az accesshez képest. Milyen a VB2005?


    Remek! Érdemes kipróbálni..

    Mutasd a teljes hozzászólást!
  • Sziasztok,

    Köszönöm a válaszokat, és a felajánlott segítséget!

    A VB6-ban és VB.NET 2003-ban volt már néhány projectem, pár űrlapos kis alkalmazások. Kiolvastam egy rakat VB6 könyvet, meg a Holzner féle VB.NET Fekete Könyvet. Sem a C#-al, sem a VB.NET 2005-el még nem volt időm foglalkozni.

    A fejlesztő eszközre vonatkozó döntésben (Access vs VB.NET 2005) kérem a segítségeteket:

    1. Úgy tudom, hogy a VS expressz verzió csak saját használatú sw fejlesztéshez ad jogot (mondjuk tanulni jó). Mennyi a VB.NET 2005 fejlesztő ára?.

    2. Az SBS 2003-hoz csak a SQL 2000 jár. Ezt a példányt lehet-e upgradelni?

    3. Az MS-nek van-e még fejlesztő támogatási konstrukciója?

    4. Cca mennyi tanulási idő kell VB.NET 2005-höz, és milyen könyvet javasoltok (elsősorban adatbázis alkalmazások fejlesztése)

    5. Elég sok tételsoros rögzítésem van. Az Accessben erre a folyamatos nézetű segédűrlap egy jó és gyors megoldást szolgált (összes vezérlő használható). Milyen megoldás vált be Nektek VB.NET-ben?

    6. A fejlesztési időből sokat elvisz a hibakeresés és javítás. Az Accessben a futó kódot át tudom írni, visszahúzom a mutatót, és újra rá tudok állni a javított sorra. A 2003-nál nem tudtam átírni a kódot runtime. Mi a helyzet 2005-nél?
    Általában a teljes fejlesztési idő uarra az alkalmazásra milyen Accessben és VB.NET-ben?

    7. A VB6-nál CR8.5-öt használtam a listák gyártásához. Azt tudom, hogy a CR a VS része lett. Akkor vezették be a központi CR szervert. Sok változás van?

    8. Tudom, hogy az SQL szervernél a válaszidők már az adatbázis tervezésekor nagyrészt eldölnek. Az Access-es tábla, index, és integritás tervezési gyakorlattól miben tér el az SQL szerveres?

    9. Az Access combobox elég rugalmas, van rágépelési lehetőség. Az eddigi VB verziókba a gyári datacombo, combo, listbox, Datalist elég fapadosnak tűntek. Milyen a VB2005-ös megoldás?

    10. Vannak olyan törzstábláim, amiben a rekordszám meghaladja a 64k-t, ami a combo és listboxok max mérete. Ezért kellet készíteni egy textbox alapú vezérlőt, amibe a begépelési sebességnek megfelelő sebességgel fel kell tölteni adatbázisból a neki addig beírt szövegnek megfelelő rekord egy adott mezőtartalmát (LIKE *). A korábbi VB verzióknál elég lassúnak tűnt a LIKE*-os SQL szerveres lekérdezés az accesshez képest. Van erre bevált, gyors megoldás a VB2005-SQL2005-ben?

    11. A űrlapok (törzskarbantartók, rögzítések, listamaszkok) gyártása meglehetősen unalmas, egyhangú munka. Ráadásul nagyon körülményes volt a vezérlők felhelyezése, elrendezése, vagy átrendezése a korábbi VB verziókban az accesshez képest. Milyen a VB2005?

    12. Vannak távoli munkaállomások. Ezek most terminálszerveren futnak. Az SQL server port alapú, elvileg neten is csatlakozhat hozzá kliens. De szóbajöhet web alapú elérés is. Mi a jó gyakorlat?

    13. A web alapú eléréshez a Visual Web Dev 2005 elég jó?

    Bocs, egy kicsit sok lett, dehát tényleg érezni szeretném a különbséget!



    Mutasd a teljes hozzászólást!
  • Csak azt tudom mondani, hogy én mit csináltam.

    Az Access továbbfejlesztő varázslójával átalakíttattam Access projekté, majd, a program logikája mentén haladva, az egyes funkciókat "felélesztettem".

    Többször megfordult a fejemben, hogy nem egyszerűbb-e újra írni? Sőt voltak olyan részek, melyek egyébként is átalakításra vártak, ahol megtartottam az űrlapot, de mögötte mindent átírtam.

    A táblákat a rendszer átteszi az sqlszerverre, az űrlapok, riportok maradnak, és használhatóak. A VB kódok részben jók, részben átírandók. A lekérdezéseknek nálam vagy 80%-át újra kellett írni.

    Az sqlszerver kényesebb néhány dologra, mint az Access, jó néhányszor megszívatott.

    Viszont az átírás után sokkal hatékonyabban működik.

    Ha lenne elegendő jártasságom a VB, nem a VBA, használatában és időm az űrlapok, és riportok újraírásához, elgondolkoznék Riha javaslatán.

    Természetesen, ha az Access mellett maradsz, akár közvetlen megkeresésre is , segítek, ha tudok, és ahogy a Riha írja mások is megteszik.




    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