MS Access, mint adatbázis-motor?

Adatbázis: SQL, XML DB

Ügyfelem szeretne telepíteni egy olyan szoftvert, ami nem MSSQL szervert, hanem (állítólag) MS Access-t használ adatbázis backendnek. A program a dokumentáció alapján alkalmas több kliensről konkurrens használatra... (A licenszelése is konkurrens júzerek száma alapján történik)

Kérdésem, hogy ez mennyire enterspájz megoldás? Oké, persze, semennyire, de aki látott már ilyet, mit tapasztalt? Lockolási problémák, például? A helyzet annyiból rózsás, hogy nem fájlszerveren csücsülnének a db fájlok, hanem egy terminálszerveren érnék el a kliensek helyből...

  • 4806 megtekintés

( Cseresznye | 2011. 12. 11., v – 23:46 )

Ez elég meredeken hangzik. SQL Express sem játszik?

( Nyosigomboc v | 2011. 12. 11., v – 23:58 )

A Microsoft mar legalabb 5 eve nem ajanlja az Access hasznalatat, pedig ugye ok irtak..
Nincs alternativa? (masik program, masik DB, esetleg ehelyett egy masik ugyfel..)

--
"The greatest thing about the internet, is that you can quote something and totally make up the source." - George Washington

( tovis v | 2011. 12. 12., h – 01:20 )

Szépen le kell neki írni, a kifogásokat, és áthárítani az adatvesztésekkel és egyéb zavarokkal járó kockázatot az ügyfeledre - csak az Ő felelősségére. Southe Park - senkinek nem ajánljuk!
Tedd fel, gondoskodj a periodikus adatmentésről - valami megbízható helyre, és háríts minden kifogást.

* Én egy indián vagyok. Minden indián hazudik.

( b | 2011. 12. 12., h – 02:45 )

Mond azt neki, hogy ez így nagyon durva.

Az a gond, hogy a Nagy Magyar Ugaron az ilyen megoldás nem túl ritka. Néha azonnal el szeretnék ilyenkor rohanni az országból.

--
GPLv3-as hozzászólás.

( borbelyimi | 2011. 12. 12., h – 07:27 )

Szia!

Azért mielőtt lehúznánk az Accesst jó lenne tudni, hogy mire akarják használni a programot!
Nálunk fut néhány Access adatbázis, ilyen-olyan kisebb nyilvántartásokra teljesen jó. Egy sima fájlszerveren megosztva tökéletesen működik.
Egy több száz fős cég bérszámfejtését már én sem bíznám rá.

Üdv,
Imi

( vl v | 2011. 12. 15., cs – 11:49 )

de aki látott már ilyet, mit tapasztalt?

Az a tapasztalat, hogy ha egy sw írásánál nem megfelelő technológiát használnak/tak, akkor azoknál a sw-eknél a lehető legritkább esetben vannak rendben a dolgok. Nem azért, mert nem a megfelelő technológia van mögötte (ez ugyanis csak a tünet), hanem azért, mert aki ilyen "hibát" vét, az általában más dolgokat is rosszul csinál meg (= a program tele lesz olyan "elbaszásokkal", amiket rendes programban nem találnál meg, csak hát aki ilyeneket követ el, az nem rendes programozó).

( furge | 2011. 12. 15., cs – 12:08 )

láttam én már hasonlót.

ott is fájlokban tartotta a rendszer az adatbázist. terminal szerveren érték el. legnagyobb gond az volt, hogy ha nem szabályosan zárták be a programot (ami egy terminal szerverben marad session, futó példány tétlenség miatt kidobja a felhasználóval nem volt nehéz elkövetni) akkor összeborult az adatbázis indexelése. magával vont egy olyat, hogy addig nem indult el míg újra nem indexted. ezért vagy a szerver conlose-n mindig futott egy példány belőle vagy ha nem akkor minden nap hajnali 3ra ütemeztem egy automata újraindexelést. szerencsére volt benne ilyen funkció

a legszebb az volt, hogy tudta volna kezelni az mssql2000. de annak idején úgy gondolták, hogy jobb ez így.

hát igen. és ők ezt a progit erp rendszerként használták. ja meg emelet a Epicor iScala-t is. de azt csak könyvelésre (mert a másikban nem volt könyvelő modul). és amikor szóba került a továbbfejlesztés és a két rendszer egyesítése akkor inkább ezt az őrültséget választották.