SQL forespørgsel fra 2 forskellige databaser?

Christian iMARKETING:

jeg har arbejdet med Access i 10 år nu til webbrug og ikke een eneste gang har det givet nogen som helst probleme

Så har du aldrig haft ret mange samtidige besøg :)

Jeg er helt enig i at du bør flytte til MS SQL. Jeg startede også selv i tidernes morgen med MS Access, men ikke lang tid - da jeg først fik prøvet med MS SQL, og MySQL var der ingten vej tilbage. Det er simpelt hen 1000 gange federe.

En hosted MS SQL server koster i dag så lidt, at der ikke er nogle gode undskyldinger for at lade være.

Christian iMARKETING:

Til jer andre, der fortæller at Access er fy, fy skamme, så kan jeg sige, at jeg har arbejdet med Access i 10 år nu til webbrug og ikke een eneste gang har det givet nogen som helst problemer

Jeg har haft problemer med Access og flere-brugere! I bedste fald en misset skrivning, men det skete også at databasen blev korrupt og ikke kunne åbnes. Så jeg tilhører nok den lejr, der ikke ville turde at sætte en Access i enden af et web-baseret system.

Men hvorfor også tage chancen, den eneste grund til at bruge Access, er hvis man ikke kan overkomme at sætte sig ind i en server-baseret database. Man har jo masser af gratis alternativer som bedre og også koster gratis :-)

Christian iMARKETING:

Jeg bakker lige op her.

Var i "Rabatten" med www.Pillefyring.dk og det gav selfølgelig en ordentlig belastning på serveren; men den gik ikke ned af denne grund.

Ville nok ikke anvendes Acces hvor rigtig mange forskellige brugere simultant skriver til databasen såsom Amino

Venlig hilsen,

Christian

Ved masser af samtidige læsninger får du sansynligvis bare timeouts hvis det går hedt til - Det er lige præcis antallet af samtidige skrivninger der er problemet. Og som jeg læser problemstillingen er det netop et antal kasseapparater der skal skrive kasse-transaktioner i databasen  - og risikoen for fejlskrivninger stiger med antallet af kasseapparater og varesalg.

Omvendt, hvis hvert kasseapparat har sin egen accessdatabase, som synkroniserer med en central database, så vil det sansnyligvis ikke give problemer.

Så min anbefaling vil stadig være at samle de data der skal samles, og så lave dit query i den centrale database - især hvis du skal skrive i database(erne) - da du så vil kunne lave alt inden for samme transaktion og har mulighed for at lave rollback hvis noget går galt. Den mulighed mister du hvis du har flere databaser.

mvh

Jan

Lundsby:

Jeg har haft problemer med Access og flere-brugere! I bedste fald en misset skrivning, men det skete også at databasen blev korrupt og ikke kunne åbnes. Så jeg tilhører nok den lejr, der ikke ville turde at sætte en Access i enden af et web-baseret system.

Det der gjorde at jeg valgte Access fra er simpelhent en opdatering af "databasen" vil betyde at sitet skulle lukkes ned imens det skete.

Niels:

Det der gjorde at jeg valgte Access fra er simpelhent en opdatering af "databasen" vil betyde at sitet skulle lukkes ned imens det skete.

Det er dette problem jeg har løst med de 2 databaser

Kassedatabasen bliver simpelthen skiftet ud med en ny på et splitsekund en gang i døgnet hvorefter den bliver opdateret hver 5. minut.

Mikkel, jeg kan godt forstå dig. Vores system har een gang kørt på MS SQL for en del år siden, hvor en stor kunde havde 120 butikker der alle skulle kunne opdatere data.

Men for et ganske almindeligt CMS er det stadig min erfaring at det er "overkill" at køre med andet end det, der i årevis har vist sig at fungere ganske udmærket.

Jeg troede lige, at jeg blev nødt til at skifte - så hvis ikke Jesper var kommet med sit forslag, så ville jeg sikkert have følt, at jeg endelig løb imod "muren" med Access.

Eet eller andet sted kan jeg altså rigtig godt lide, at jeg hurtigt kan tage en backup af en database og sige til mig selv, at her er en fil der ser sådan og sådan ud på dette tidspunkt.

Der findes sikkert 100 måder man kan få noget tilsvarende frem med MS SQL; men grundlæggende har jeg det godt med at lade være med at bygge større løsninger hvis tingene kan løses på en enkel måde

Venlig hilsen,

Christian

Christian iMARKETING:

Der findes sikkert 100 måder man kan få noget tilsvarende frem med MS SQL; men grundlæggende har jeg det godt med at lade være med at bygge større løsninger hvis tingene kan løses på en enkel måde

Det er ikke et spørgsmål om at Access er en simplere løsning, på nogle områder kan Access faktisk meget mere end SQL Server.
Det er mere et spørgsmål om at bruge produkterne til det de er beregnet til. Access er et udemærket produkt som lokalt datastore til en Windows Applikation evt. en applikation udviklet i selve Access.

Men Access er ikke beregnet som datastore for en webapplikation, eller en fler-bruger client-server løsning, her bør man bruge en SQL Server.

Der er selvfølgeligt lidt en indlæringskurve i starten, men på den lidt længere bane så er det bare lettere at bruge produkterne til det de er beregnet til.

Christian, for mig er det lidt ligesom med streaming video. Det kan man også godt gøre over http fra en almindelig webserver. Men den er ikke beregnet til det. Og når nu det er SÅ let i dag at lægge sine videoer ud på en dedikeret video streaming server eller tjeneste er det helt åndssvagt ikke at gøre det.

Som Lundsby så rigtigt siger handler det om at bruge værktøjerne til det de er bedst til - det synes jeg næsten altid man kommer længest med.