Nyilvantarto rendszer+ Access licenszelése
2009-12-03T18:33:03+01:00
2009-12-04T18:57:45+01:00
2022-07-19T05:12:25+02:00
  • Sziasztok!

    Először is köszönöm mindenkinek a hozzászólást. A leírtakhoz a következőt tenném hozzá. Én is tisztában vagyok azzal hogy egy ilyen nyilvántartó rendszer minden elemét külön arra a célra létrehozott fejlesztőeszközökkel és programokkal lehet a legprofibban megoldani. Tehát az adatbázishoz MSSQL Servert használok a fejlesztéshez Visual Studio-t amit kiegészítek néhány komponenssel ami segíthet az alkalmazás létrehozásában.

    DE azért mindig fel kell mérni a szükségleteket is! Tényleg szükség van rá? Például nekem az a célom hogy teszt céllal minél gyorsabban be tudjak mutatni egy működő rendszert. És persze minél olcsóbban. Nyilván hamarabb összehozok egy demot access-el reportokkal lekérdezésekkel űrlapokkal együtt, ráadásul a gépeiken csak a runtime-ot futtatnám.

    Most azt vizsgálom hogy hogyan lehet szükség esetén (például 1 év múlva) tovább skálázni. Tehát lecserélni az adatbázist...

    Amúgy itt egy cikk az Access2007-tel létrehozott egy fájlos rendszer (tehát együtt az AB és alkalmazás) szeparálására:
    Deploy an Access 2007 application
    Mutasd a teljes hozzászólást!
  • Hol van az accessben Sql SZERVER ?

    Látom halvány fogalmad sincs az Acces-hez. Ez nem vita tárgya, tény. Nem kéne nyilatkoznod arról, amirt nem tudsz.

    Ismerek pár dobozos ügyviteli szoftvert, meg láttam pár nem dobozosat is accessben. Olyat ami jelentős lett volna és accessben követték el nem igazán. Ezzel együtt nem mondom hogy nem lehet ilyet csinálni.

    Amiről nem tudsz, az még lehet. Ez is csak ismereteid hiányát bizonyítja.

    Csak mondjuk aki egy normális programnyelvet/környezetet nem tud megtanulni az jó eséllyel a normálformákkal sem igen van nagy barátságban.

    Miért akarod kötelezően eldönteni (más helyett), mi a jó programnyelv. Bármilyen nyelvvel le lehet kezelni az SQL-t. Ismét: az adatbázistervezés teljesen független a programnyelvtől.

    Egyébként Micu részletesen (ezt is) kifejtette: nem szoktunk repülővel vásárolni menni a sarokra. Lehet, de minek????
    Mutasd a teljes hozzászólást!
  • Ilyen alapon a C#-al alapvetően az a baja, hogy nem adatbázis szerver.

    Mi köze egy programnyelvnek egy adatbázismotorhoz ? A VBA egy dolog, az mdb és a körülötte lévő architektúra egy másik dolog. Én itt az adatbázismotorról beszéltem, nem a VBA-ról.

    Ilyen alapon Excel-t se használjunk... 200 sort beírni, szűrni, keresni, összesíteni teljesen használhatatlan, mert nem szerver.

    Az excelnek megvan a maga jól behatárolható funkciója.
    Ezzel nincs is semmi gond, amíg nem próbálják ügyviteli
    szoftnak használni. Mert már láttam ilyet... Ne tudd meg.
    Az accessnek sem lenne semmi baja addig amíg arra
    használják amire való: a házi DVD lemezgyűjteményünk
    nyilvántartására. Ott a gond amikor ügyvitelesdit játszanak vele.

    Bocs, mennyivel jobb, hogy van egy C# programod, ami egy szerveren keresztül cseszeget egy fájlt? Mert ha jól tudom, akkor egy MSSQL adatbázis is csak egy fájl a merevlemezen.

    Nem. A MS-SQL egy SQL szerver. Amikor a programod megkéri hogy adja ki azokat a sorokat amikben a név mezőben szerepel a "csavar" szó valahol, akkor szépen végigmegy a táblán, ez alapján generál egy resultsetet és ezt elküldi a programodnak. Közben persze cache-elget is hogy a számodra érdekes adatok legközelebb is kéznél legyenek. Ehhez képest ha ugyanezt megkérdezed egy access-es mdb-től akkor a programod szépen áthúzza a hálón az egész táblát és úgy válogatja le a "csavar"-t tartalmazó sorokat. És persze nem igazán tud gyorsítótárat sem optimalizálni.

    Arról nem szólva hogy ha a programodban történik valami toxikus akkor sérülhet is az adatbázisfájl (régen amikor használtam ilyesmit láttam már ilyet accessnél meg dbf-nél is). Na most, SQL szervernél mivel a programod nincs közvetlen kapcsolatban a fájllal nem igazán fordulhat elő ilyen.

    Nem fejlesztői erőforrás pazarló, hogy azért mert egy jelentésen változtatnom kell, és ehhez a forrás lekérdezésen változtatni kell, akkor (nem számolom) hány programhoz, fájlhoz kell hozzányúlnom?

    Attól függ hogy hogyan oldod meg a report készítést. Sokféle megoldás létezik a fastreporttól kezdve amit én favorizálók a crystal reportson át a reporting services-ig. Ez utóbbival a júzer is csinálhat reportot az accesshez hasonlóan. Bár én nem igazán vagyok ennek híve.

    Bocs Windowsban cmd-t használsz? Mert a mai kívánalmaktól fényévekre van.

    Elég ritkán. Inkább powershell-t de az sem nagyon kell.

    Egy C#-MSSQL környezettel ez mennyi idő, ha éppen utazol valahova?

    Lásd fenn.

    Személyeskedő: Te pl. a C# minden lehetőségét kihasználtad már?

    Nem. De sok olyat használok naponta amiről VBA-ban csak álmodhatsz.

    Mert én úgy emlékeztem, hogy abban is vannak elágazások, ciklusok kiírások, ami az egész programozás ocsmány alapja.

    Ahogy az assemblyben is. Te azt használod ? Pedig sok erőforrást meg lehet ám spórolni vele

    Amúgy nézz körbe Pl. a LinQ, lambda expressions, generics környékén...
    Mutasd a teljes hozzászólást!
  • Örülök, hogy neki válaszként elmondtad, amit már leírtam, hogy miért nincs így.

    Ezt azért így nem mondanám. Szerintem próbálj ki pár másikat úgy hogy pár hónapig dolgozol bennük és aztán döntsd el hogy mi a VBA.


    Azért megnézem neked C#-ban mekkora meló egy új függvényt megírni az Access/Excel-hez, és mekkora nekem VBA-ban.

    Feladathoz eszköz választás


    Persze. Csak mondjuk aki egy normális programnyelvet/környezetet nem tud megtanulni az jó eséllyel a normálformákkal sem igen van nagy barátságban. Persze tisztelet a kivételnek.


    De semmi biztosíték nincs arra, hogy egy normális programnyelvet használó megtanulta mindezeket.
    Mert ha nem, akkor "normál" programnyelv és "normális" sql szerver mellett is tud rossz adatbázissal dolgozni.

    Ha van egy autód akkor nem fogsz háromkerekű biciklivel menni a szomszéd faluba sem, akkor sem ha amúgy 3 kerekű biciklivel is oda lehet érni.

    De ha van egy biciklid, akkor 1 km-re lévő kenyérboltba se úgy fogsz menni, hogy kiállsz a garázsból, becsukod a garázskaput, elautókázol, leparkolsz, vásárolsz, megfordulsz, visszamész kinyitod a garázskaput, beállsz a garázsba.

    Vagy ha igen, meg is érdemled, de hogy nem költségoptimalizált megoldás az is biztos.

    Megint csak egy dolgot hagytál figyelmenkívül, mint eddig az összes hozzászólásodban:

    Feladathoz kell eszközt választani.
    1 km-ért nem fogok autót használni, ha van biciklim (és persze nem esernyőként használom a kocsimat)
    50 km-t már nem (feltétlenül) fogok kerékpározni.
    USA-ba már nem is fogok autóval menni, hiában van autóm. Pl. már nem is biztos, hogy egy kétéltű autóval érdemes nekiindulni.
    Mutasd a teljes hozzászólást!
  • Az access-ben van egy SQL szerver, mely pontosan ugyanúgy ahogy egy akármilyen SQL szervernél a futó alkalmazás feladatot ad a szervernek.

    Hol van az accessben Sql SZERVER ?

    Nem kéne lehülyézni azokat, akik jelenzős eredményeket érnek értek el ebben a rendszerben.

    Ismerek pár dobozos ügyviteli szoftvert, meg láttam pár nem dobozosat is accessben. Olyat ami jelentős lett volna és accessben követték el nem igazán. Ezzel együtt nem mondom hogy nem lehet ilyet csinálni. Csak azt, hogy akik képesek ilyet csinálni azoknak profibb eszközök is a rendelkezésére állnak.

    Ha a hülye Pistike megtanulja a VBA-t, akkor egy normális programnyelvet tanult meg.

    Ezt azért így nem mondanám. Szerintem próbálj ki pár másikat úgy hogy pár hónapig dolgozol bennük és aztán döntsd el hogy mi a VBA.

    Nem mellékesen: pontosan ugyanúgy kell Accessben adatbázist tervezni.

    Persze. Csak mondjuk aki egy normális programnyelvet/környezetet nem tud megtanulni az jó eséllyel a normálformákkal sem igen van nagy barátságban. Persze tisztelet a kivételnek.

    Továbbiakban: Egyszerűbb feladatokat szakmai bűn a nem megfelelő eszközökkel (itt ágyuval verébre lövésre gondolok) megoldani.

    Ha van egy autód akkor nem fogsz háromkerekű biciklivel menni a szomszéd faluba sem, akkor sem ha amúgy 3 kerekű biciklivel is oda lehet érni.
    Mutasd a teljes hozzászólást!
  • Az adatbázismotorral alapvetően az a baj hogy nem szerver.


    Ilyen alapon a C#-al alapvetően az a baja, hogy nem adatbázis szerver. (txt fájlt azért ne tekintsük adatbázisnak )
    Tudom ez a kijelentés önmagában ba...ság. De olyat a szemére hányni egy alkalmazásnak, ami nem célja, az is elég érdekes.

    Tehát az Access hibája, hogy nem szerver? Nem az a célja, hogy több 10-100-.. felhasználót szolgáljon ki. A célja, hogy egy kis "közösség" igényeinek eleget tegyen.

    Ilyen alapon Excel-t se használjunk, mert teljesen logikátlan, hogy egy oszlopban az összes (hasznos sorban) lefoglalunk egy cellát, hogy lássuk az egységár*mennyiség értékét. Ha mást akarunk számolni, akkor az összes cellát át kell írni. (Ez ugyan nem feltétlenül igaz, de most Nem Excel trükkök tanfolyam van )
    200 sort beírni, szűrni, keresni, összesíteni teljesen használhatatlan, mert nem szerver.

    Az Opelem hibája akkor, hogy nem repülő?


    Az access esetében pedig van egy fájlod amit közvetlenül cseszeget a program

    Tedd külön az adatokat és a "programot" és akkor nem közvetlenül "cseszegeti"

    Bocs, mennyivel jobb, hogy van egy C# programod, ami egy szerveren keresztül cseszeget egy fájlt? Mert ha jól tudom, akkor egy MSSQL adatbázis is csak egy fájl a merevlemezen.
    Tehát "nem Access"-nél van "egy" fájl, ami az előállított, futtatott programod, van "egy" fájl, ami az sql szerver, és van egy fájl, ami "az" adatbázis.
    Nem egy kicsit számítógép erőforrás pazarló?

    Nem fejlesztői erőforrás pazarló, hogy azért mert egy jelentésen változtatnom kell, és ehhez a forrás lekérdezésen változtatni kell, akkor (nem számolom) hány programhoz, fájlhoz kell hozzányúlnom?

    Másfelöl kicsit sarkítva: Az (MSSQL) adatbázisban lévő tárolt eljárás mit is csinál?
    van egy fájlod amit közvetlenül cseszeget a program


    Miért jobb a közvetet, mint a közvetlen? Mi előnye van egy tolmácson keresztül beszélgetni, mint közvetlenül?
    És most ne általánosítva határozzuk meg, hanem egy célfeladat szerint.

    Azt se nézzük, hogy van Access adp (tehát Access fejlesztőkörnyezet MSSQL szerver adatbázissal)

    Ez főleg több felhasználós környezetben nagyon nem mindegy

    Nem cél hogy "sok" felhasználót szolgáljon ki.
    Mint ahogy egy sql szervert se használsz ahhoz, hogy 2 számot összeadjál (pedig lehetne), ugyan úgy nem biztos (sőt szerintem biztos, hogy nem), hogy érdemes 2-5 felhasználóhoz sql szervert telepíteni.

    Magával az accessel alapvetően az a gond hogy a mai rendszerektől ...

    Bocs Windowsban cmd-t használsz? Mert a mai kívánalmaktól fényévekre van.

    És igazán nem nagyon látok érvet mellette azon kívül

    Pedig már kérdeztem korábba is.
    "Felhívtak, hogy valami extra infó kellene a főnöknek."

    Egy C#-MSSQL környezettel ez mennyi idő, ha éppen utazol valahova?

    illetve a programozáshoz szükséges többi apróságot, hanem Pl. adatbázist tervezni sem

    Mert akik itt a prog.hu-n mysql, mssql, ... adatbázisokat használnak, azok mind optimális adatbázis tervet alkalmaznak?
    Most kb. azt mondod, hogy ne használjunk késeket, mert vannak akik az éles felét szorítják meg.
    Most az eszköz hibája, hogy rosszul használják, a gyártóé, hogy ad eszközt, vagy a felhasználóé, hogy rosszul használja?

    úgy fél évet programozni C# 3.0-ban úgy hogy ki is használod a lehetőségeit.

    Személyeskedő: Te pl. a C# minden lehetőségét kihasználtad már?

    Nem szemlyeskedő: Vagy kihasználtad a VBA összes lehetőségét, hogy tudod, egy feladathoz mi az elég?
    Nem értem, ha pl. a C# mindent csodálatosan tud számolni, és még zöldre is tudja festeni az eget, az nekem mennyivel jobb, mint a VB, ami tökéletesen számol, de nem festi az eget, mert a feladat megoldásához sosem hiányzott.

    az az alapjául szolgáló bézik miatt szintén kicsit ocsmány jószág.

    Azt hiszem meg kellene alaposabban ismerkednem a C# 3.0-al?
    Mert én úgy emlékeztem, hogy abban is vannak elágazások, ciklusok kiírások, ami az egész programozás ocsmány alapja.

    Mert te most a szintaktikán problémázol.
    Mennyivel jobb ez:
    for (int i=1; i<10; i++)
    Mint ez:
    for i=1 to 9 step 1 ' step 1-et nem kellene megadni, alapértelmezett

    vagy
    do {
    } while (i<30);
    mint
    do

    loop while i<30


    Utána szerintem te is látni fogod mi a gond vele

    Látom. De én azt is látom, hogy egy feladathoz eszközt kell választani, és nem azt mondani, hogy a (pl. C#) fejlesztőeszköz mindent meg tud csinálni (amire semmi szükségem), ezért vegyek (vagy "csak" telepítsek)
    egy C# (fordítót)
    egy SQL szervert
    egy report generátort
    amikor a feladatnak bőven eleget tesz
    egy Access

    Tényleg? Minek a nagyobb az erőforrás (memória/proci/tárhely) igénye? C#+MSSQL, vagy Access (futtatókörnyezet)

    --
    egy rakás olyan dolgot megcsinálhatsz vele amit accessel soha az életben
    nem is akarsz, mert nem feladatod.
    Nem veszek azért egy repülőt, hogy az egy kilométerre lévő boltba naponta elmenjek.

    ==

    De melyikben készül el gyorsabban?
    Ismerőseidet (telefonszámaikkal, hobbijukkal) kell egy adatbázisban tárolni, hogy legyen pár űrlap az ismerősők, telefonszámok, hobbik felviteléhez, ismerősök közötti kereséshez, szűréshez, rendezéshez, és legyenek nyomtathatók különböző formában (kezdőbetűs kiemelt, hobbi szerint csoportosított) listák.
    Feleséged veled egyidőben másik gépről is szeretné használni.


    Mielött valaki adna egy feladatot, ami Access-ben nem (vagy csak sokkal nehezebben) oldható meg, a félreértések elkerülése végett:
    Szerintem lehet létjogosultsága, sőt van amikor kell C# (vagy más),
    (elszeparált GUI / BL / DL, stb
    ,) sql szerver.
    De általánosan azt mondani, hogy az mennyivel jobb, mint valami más, az szerintem "kicsit" túlzás.
    Mutasd a teljes hozzászólást!
  • Kedves LC! Nem értelek. Érveid nincsenek, véleményed ezenkívül általánosító, bántó. Sorban:
    1. adatbázismotor. Az access-ben van egy SQL szerver, mely pontosan ugyanúgy ahogy egy akármilyen SQL szervernél a futó alkalmazás feladatot ad a szervernek. Igen, az Accessben ez 1 felhasználó. Maga az adatbázis fájlrendszer teljesen hasonló a szerverben találhatóhoz. Ezért erről az egy kliensről igen gyors.
    2. Mi az hogy 12 fényév? Ez nem érv. Nem kéne lehülyézni azokat, akik jelenzős eredményeket érnek értek el ebben a rendszerben. Úgy látszik ez neked nem sikerült. Vagy nem próbáltad, vagy nem vagy alkalmas rá. Ha a hülye Pistike megtanulja a VBA-t, akkor egy normális programnyelvet tanult meg. Ha nem tudnád, .Nettel is programozható az ACCESS!!! Nem mellékesen: pontosan ugyanúgy kell Accessben adatbázist tervezni. Ez teljesen független a kliensen (klienseken) futó programtól és annak nyelvétől. Ez, azt hiszem evidens, ezt sem tudtad? Hogy tudsz akkor te adatbázist tervezni?

    Továbbiakban: Egyszerűbb feladatokat szakmai bűn a nem megfelelő eszközökkel (itt ágyuval verébre lövésre gondolok) megoldani. Igen, látok egy jelentős Access ellenszenvet magyarországon. Ha megnézzük a rendszer hazáját, jelentős mértékű Access feladatmegoldások vannak. Itthon talán a köpködés abból fakadhat, hogy sok fejlesztői munkát és megbízói pénzt vinne (visz) el. Egyébként saját tapasztalatom is: 8 felhasználós kb 10000 alaprekord és 30000 kapcsolt rekordos rendszer MŰKÖDIK. Érdekes volt a rendszer átadása a megbízó cégnél: megjelent a rendszergazda és kijelentette a helyszínen több tanú előtt, hogy ez a feladat Accessel nem megoldható, és nem működhet. Akkor már 2 hete folyamatosan (nem tesztüzem) működött. Azóta sem volt pofája odajönni. Szerencsére. Szóval kérek mindenkit, nem kéne oly gyorsan lebecsülni, lenézni más, igen, néha egyszerűbb eszközökkel megoldott feladatokat, rendszereket.
    Mutasd a teljes hozzászólást!
  • Mondjuk a C#-hoz és hasonlókhoz képest ott látom a különbséget, hogy amíg nincs meg egy saját környezet C#-ban, addig csak szegényes programokat lehet írni benne.


    Miért is ?
    Alapból a windows.forms tartalmazza az összes fontos vezérlőt. Ha meg igazán csicsát akarsz akkor ott a WPF, bár annak a designer támogatása valóban béka feneke alatt van és nem is túl kezdőbarát - de egy rakás olyan dolgot megcsinálhatsz vele amit accessel soha az életben. Ahogy magával a Visual C# Express-szel is.

    Mondjuk report szempontjából viszont valóban hátrányos helyzetű. De erre vannak a report generátorok.
    Mutasd a teljes hozzászólást!
  • Az adatbázismotorral alapvetően az a baj hogy nem szerver. Egy szervernél egy átlag alkalmazás úgy néz ki hogy van az SQL szervered ami egy önálló program és van az alkalmazásod ami beszélget vele. Az access esetében pedig van egy fájlod amit közvetlenül cseszeget a program. Ez főleg több felhasználós környezetben nagyon nem mindegy. Amíg garantáltan csak egy júzered van addig nincs nagy gond vele, Pl. az én programon demóverziójához én is beágyazott SQL-t adok, szigorúan kikötve hogy csak tesztelni!. Ennek egyrészt az az előnye hogy nem kell hozzá SQL szervert telepíteni, másrészt nem kell hozzá 80 megás SQL szervert letölteni. De éles felhasználásban még egyfelhasználósnak sem javasolnám.

    Magával az accessel alapvetően az a gond hogy a mai rendszerektől (elszeparált GUI / BL / DL, stb) kb. tizenkétezer fényévre található. És igazán nem nagyon látok érvet mellette azon kívül hogy a Hülye Pistike is tud vele csinálni egy programot.
    Csakhogy a Hülye Pistike nem csak normális programozási nyelvet nem tanult meg, illetve a programozáshoz szükséges többi apróságot, hanem Pl. adatbázist tervezni sem. Aminek csúf következményei lehetnek.

    A VB-val kapcsolatban csak annyit tudok mondani hogy próbálj meg úgy fél évet programozni C# 3.0-ban úgy hogy ki is használod a lehetőségeit. Vagy akár az annak megfelelő VB.NET-tel, bár az az alapjául szolgáló bézik miatt szintén kicsit ocsmány jószág. Utána szerintem te is látni fogod mi a gond vele
    Mutasd a teljes hozzászólást!
  • Ez annyira várható volt, hogy valaki egy programozási nyelvet fog ajánlani...

    A KÉRDÉSEDRE én azt mondom, hogy jogtiszta.
    Mutasd a teljes hozzászólást!
  • Az Access ad egy elég kellemes környzetet.
    Lehet benne jól is és rosszul is programozni.

    Mondjuk a C#-hoz és hasonlókhoz képest ott látom a különbséget, hogy amíg nincs meg egy saját környezet C#-ban, addig csak szegényes programokat lehet írni benne.
    Az Access pont ezt a környezet hiányt pótolja.

    Egy bizonyos alkalmazás méret felett persze nem használható az Access, de a használható méret elég nagy.

    Nekem jelenleg futő éles Access proramom legnagyobb táblája >2.2 milló rekordot tartalmaz és szépen megy. Egyébként a problémák nem a rekordszámmal jelentkeznek.

    Amiben nagyon jó az a lekérdezés és a riportok.
    Mutasd a teljes hozzászólást!
  • Halgass a Micura, és használd nyugodtan az Accesst. Kevés gyakorlattal is hamar, látványos eredményt érhetsz el.
    Mutasd a teljes hozzászólást!
  • Áruljátok már el nekem (bár inkább egy minta érdekelne), hogy Access 2003-ban mi is a baj az "adatbázismotorral"
    Vagy a VB-el?


    Egy extra lekérdezést a használónál "más" rendszerben hozol elöbb jelentés formába, vagy Access-el?

    Pár százezer rekord számig (bár használtam már milliós
    nagyságrendet is) simán dolgozik

    Felhívtak, hogy valami extra infó kellene a főnöknek.
    Telefonon negyed óra alatt simán lekérdeztük az infót egy olyan felhasználóval, aki elötte csak Wordöt és Excel-t látott.



    Mutasd a teljes hozzászólást!
  • Szerintem is felsleges accessel bajlódni.
    Már íratták át velem nem egyszer access-es progit, mert rájöttek hamar, hogy nem az a megfelelő.
    Egy összetettebb raktárkészletkezelőt meg kár is elkezdeni vele.
    Accessben max csak riportozni szabad, vagy 1 felhasználós alkalmazást írni, de én azt se accessel tenném.
    Mutasd a teljes hozzászólást!
  • Mondjuk egy bézik alapú izé egybegyúrva egy több mint gázos "adatbázismotorral". De alapvetően nem vele van a gond, elveben kisebb dolgokat össze lehet vele rakni. Csak az egész Pistike nekiáll információs rendszert fejleszteni éles környezetben az ami a gond vele. Láttam már pár ilyen jellegű rendszert, ezért van az hogy az accesst kb. olyasminek látom mint a sugárhajtóművel felszerelt háromkerekű biciklit, vagy a tanuljuk meg a vakbél megoperálását 24 óra alatt című könyvet.
    Mutasd a teljes hozzászólást!
  • Úgy tudom, ahogy írtad, az már jogtiszta.
    Mutasd a teljes hozzászólást!
  • Mindenki csak szidni tudja szegény a szegény Access-t.
    Mutasd a teljes hozzászólást!
  • Felejtsd el az access-t. A Visual C# Express ingyen van.
    Aki meg nem tud vele programozni az Accessel is csak taknyolni fog, aminek a vége az lesz hogy az egész jóval többe kerül a végén mint ha megcsináltatjátok olyasvalakivel aki már látott fejlesztőeszközt és programnyelvet, viszont legalább instabil és lassú. A történet végén meg aki újraírja majd az egészet még szenvedhet a meglévő adatok importálásával is.
    Mutasd a teljes hozzászólást!
  • Jogtiszta! MSSQL express ingyenes.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Egy kis segítséget kérnék a következőkben. Egy kis cég szeretne bevezetni informatikai nyilvántartó rendszert a termékeik követésére, raktárkészletük nyilvántartására. Három ponton kell hozzáférni az adatbázishoz (Ez tekinthetjük max egyidejű hozzáférésnek). Két alkalmazott vinné be az adatok egy részét a termelés, árufeltöltés közben. Ezenkívül a főnök is felvihet adatokat plusz lekérdezéseket, jelentéseket kérhet le, exportálhat.

    Szerintem kezdetben teljesen megfelel egy Access2007 alapú rendszer. Szükség esetén a backend-et pedig le lehet cserélni MSSQL Server-re. Amit nem tudok hogy egy ilyen rendszerhez milyen licenszeket kell megvásárolni. Ugye létezik Access Runtime ami ingyenes, ez elég lenne mind a három ponton. (ugyanis nem hoznak létre új lekérdezéseket, nem módosítják az alkalmazást)

    Ha nekem van jogtiszta Access2007 és kifejlesztem a rendszert, legenerálom és a cégnél már csak a runtime lenne alkalmazva mind a 3 gépen az úgy jogtiszta? Vagy nekik is kell egy licensz?

    Kösz
    Mutasd a teljes hozzászólást!
Ez a téma lezárásra került a moderátor által. A lezárás oka: Off-topik (hogy mi�rt kell mindig... :.(...)
abcd