[VB6/HTML] Webbased database bouwen zónder inetverbinding

[kakanox]

Ik wil webbased een database draaien (dwz: in een internetvenster of iig iets dat een html-achtig bestand uitleest).

er moet dus dynamische data in, uitgelezen uit een database, maar ik heb niet de beschikking over een webserver!

waar ik het mee moet doen is het een gesharede schijf en een tooltje dat ik kan installeren bij alle gebruikers.

mijn plan was dus om een access database te bouwen, met een berg visual basic tooltjes die hierop inloggen. vervolgens moet het tooltje met internet explorer aan te sturen zijn; een soort van lokale webserver eigenlijk dus. ik heb niet de mogelijkheid om een reeds bestaande toepassing te installeren. heb wel al wat zitten googlen, maar het is niet mijn bedoeling om een volledige webserver op te bouwen en die aan te spreken via de loopback; het moet snel gerealiseerd kunnen worden! iemand ideeën?

[Vunzz]

Ik moet zeggen dat ik niet erg veel van je verhaal begrijp, maar als je het snel wilt realiseren (wat het ook mag zijn), dan stel ik toch voor dat je IIS of Apache op een servertje knalt.
Zo ingewikkeld is dat niet...

[swampy]

Dus in het kort

- Een database bestuurt via een "webpagina"
- Het is niet online
- Je Initiele idee is om via VBscript een acces database aan te sturen

Een beetje draconisch maar mogelijk, zorg er wel voor dat je precies weet welke databehoefte er is en wie erbij mogen komen.

Ik persoonlijk zuig als het op scripten aan komt dus zal iemand anders je verder moeten helpen!

[simon]

Zodra je een systeem hebt dat webpagina's serveert heb je 't over een webserver, of er nou een internet connectie is of niet.

[kakanox]

Vunzz schreef op donderdag 21 april 2005 @ 13:11:
Ik moet zeggen dat ik niet erg veel van je verhaal begrijp, maar als je het snel wilt realiseren (wat het ook mag zijn), dan stel ik toch voor dat je IIS of Apache op een servertje knalt.
Zo ingewikkeld is dat niet...

waarom worden er hier altijd dingen voorgesteld die niet mogelijk zijn?

ik heb hier op mijn werk niet de mogelijkheid om een servertje neer te knallen...

Zodra je een systeem hebt dat webpagina's serveert heb je 't over een webserver, of er nou een internet connectie is of niet.

Ook prima... ik wil dus een webservertje dat lokaal draait, heel beperkt, en info uitleest uit een MS Access database...

Dus in het kort

- Een database bestuurt via een "webpagina"
- Het is niet online
- Je Initiele idee is om via VBscript een acces database aan te sturen

Een beetje draconisch maar mogelijk, zorg er wel voor dat je precies weet welke databehoefte er is en wie erbij mogen komen.

Exactly... Je begrijpt het bijna. Het is de bedoeling om via Visual Basic (een executable) een access database aan te sturen. Misschien kan het ook wel via VBScript though, nog niet over nagedacht, omdat ik VBScript zo goed als niet ken... Kan dit client-sided? Dan heb ik de hele tussenliggende VB-executable niet nodig..

[ Voor 50% gewijzigd door kakanox op 21-04-2005 13:29 . Reden: beetje brutaal ;) ]

[Vunzz]

kakanox schreef op donderdag 21 april 2005 @ 13:20:
[...]
ik heb hier op mijn werk niet de mogelijkheid om een servertje neer te knallen...

Waar gaat die database dan op draaien? Of komt er lokaal op ieder werkstation een kopie van een Acces databaseje te staan?
Op zich kan je natuurlijk gewoon op ieder station een HTML bestand zetten.

fatsoenlijke oplossingen a.u.b..

NOFI, maar het is maar wat je fatsoenlijk noemt.

Even voor de duidelijkheid, om hoeveel users en werkstations gaat het?

[ Voor 7% gewijzigd door Vunzz op 21-04-2005 13:32 ]

[simon]

Nofi, maar probeer eens wat met een webserver tutorial.. Dit is eerlijk gezegd echt zoekwerk..

[sig69]

Ik neem aan dat je windows hebt. IIS erop, wordt standaard met elke versie meegeleverd. (Of PWS als je nog 98 draait...). Ik denk dat het anders onmogelijk wordt om een webpagina een Db aan te laten spreken.

[Creepy]

kakanox schreef op donderdag 21 april 2005 @ 13:20:
[...]
Exactly... Je begrijpt het bijna. Het is de bedoeling om via Visual Basic (een executable) een access database aan te sturen. Misschien kan het ook wel via VBScript though, nog niet over nagedacht, omdat ik VBScript zo goed als niet ken... Kan dit client-sided? Dan heb ik de hele tussenliggende VB-executable niet nodig..

Wat wil je nou?
1 - Een VB applicatiatie die een Access DB aanspreekt
2 - Een Webapplicatie die een Access DB aanspreekt

Als je 1 wilt: waarom ben je dan bezig met webpagina's?
Als je 2 wilt: Een beetje webapplicatie zonder webserver gaat niet.

Leg nu eens kort en bondig uit wat je wilt ZONDER een oplossing aan te dragen. Zeg dus niet "ik wil via vbscript in een html pagina zonder webserver een db uitlezen". Maar zeg bijv: "Ik wil een applicatie kunnen draaien met een DB erachter zonder dat er op de client iets geinstalleerd moet worden"

Tip: als het uitkomt op een applicatie die op een share staat en via de share een Access DB gaat benaderen dan kan ik daar kort in zijn: Ja dat kan en er zijn tutorials die dat voor je uitleggen

[MeIsTwisted]

volgens ziet de TS een webserver als een aparte pc?

waarom niet gewoon een acces DB. Je kan me acces ook simpel formuliertjes maken die communiceren (via VBA) met de acces DB. Met Visual Basic kan het natuurlijk ook.

[kakanox]

precies zoals in de eerste post staat:

ik heb:
- een grote share (schijf) in een server waarop ik geen admin-rechten heb en/of kan krijgen;
- 50 gebruikers met een erg gelimiteerde Windows XP (domein);

ik wil:
- een database op de share plaatsen;
- een zelfgeschreven executable op de share plaatsen;
- die executable starten op ieder werkstation;
- hierdoor een webpagina bereikbaar maken die via de executable gegevens ophaalt uit de database op de share.

volgens ziet de TS een webserver als een aparte pc?

waarom niet gewoon een acces DB. Je kan me acces ook simpel formuliertjes maken die communiceren (via VBA) met de acces DB. Met Visual Basic kan het natuurlijk ook.

het moet in een internetexplorer-venster liggen. dit d.m.v. makkelijke opbouw lijstjes en makkelijke portering naar andere software die we gebruiken.

[ Voor 38% gewijzigd door kakanox op 21-04-2005 14:49 ]

[jurri@n]

En waarom dan je gegevens via internet explorer die connect naar je vb-appje beheren? Waarom niet een vb-appje dat rechtstreeks de gegevens in de database bewerkt?

[kakanox]

jurri@n schreef op donderdag 21 april 2005 @ 14:54:
En waarom dan je gegevens via internet explorer die connect naar je vb-appje beheren? Waarom niet een vb-appje dat rechtstreeks de gegevens in de database bewerkt?

het moet in een internetexplorer-venster liggen. dit d.m.v. makkelijke opbouw lijstjes en portering naar andere software die we gebruiken.

waarom waarom? ik wil geen andere oplossing! stay ontopic please!

[ Voor 8% gewijzigd door kakanox op 21-04-2005 14:57 ]

[simon]

man man man, maak een webserver in vb. Of draai desnoods iis. Maak een prog dat je resultaten genereert vanuit de db en ze naar html wegschrijft. En kakanox is klaar.

[Blacksnak]

kakanox schreef op donderdag 21 april 2005 @ 14:56:

waarom waarom? ik wil geen andere oplossing! stay ontopic please!

Waarom de moeilijke weg opgaan als het redelijk simpel kan?

[Vunzz]

Het klinkt allemaal alsof je hoognodig eens met je systeembeheerder moet gaan praten.

[kakanox]

Vunzz schreef op donderdag 21 april 2005 @ 15:06:
Het klinkt allemaal alsof je hoognodig eens met je systeembeheerder moet gaan praten.

Ghehe, in dat stadium ben ik al geweest. ik wil het graag wél dit jaar nog oplossen... :-)

[kakanox]

Simon schreef op donderdag 21 april 2005 @ 15:02:
man man man, maak een webserver in vb. Of draai desnoods iis. Maak een prog dat je resultaten genereert vanuit de db en ze naar html wegschrijft. En kakanox is klaar.

eigelijk wel een goed idee ja... ga dat eerst eens proberen.

[Vunzz]

kakanox schreef op donderdag 21 april 2005 @ 15:13:
[...]Ghehe, in dat stadium ben ik al geweest. ik wil het graag wél dit jaar nog oplossen... :-)

Aha, dacht ik het niet... Een gebruikers die buiten Automatisering om van alles wiol installeren.
En als het kapot gaat mag de SysOp het oplossen zeker?

[kakanox]

Vunzz schreef op donderdag 21 april 2005 @ 15:14:
[...]


Aha, dacht ik het niet... Een gebruikers die buiten Automatisering om van alles wiol installeren.
En als het kapot gaat mag de SysOp het oplossen zeker?

Nee, een systeembeheerder en programmeur die iets probeert te implementeren maar nogal tegengewerkt wordt.

.......

Een dynamische excelfile die met VBA gekoppeld is aan een Access-database is dus ook mogelijk? Dat maakt het misschien ook nog wel mogelijk.

[ Voor 17% gewijzigd door kakanox op 21-04-2005 15:19 ]

[sig69]

Op mij komt het allemaal erg vaag over.
We willen een datbase uitlezen, op een share waar we geen admin rechten hebben (maar wel htmlfiles kunnen dumpen?) en het liefst in een internet explorer venster via een applicatie maar zonder webserver...

Over moeilijk doen gesproken...

Edit:
Al die omwegen die je aan het verzinnen bent zijn alleen maar lapmiddelen. Als je applicatie echt nodig is moet je het gewoon hogerop zoeken en erdoor laten drukken dat je sysadmin het jou mogelijk maakt je werk te doen.

Edit2:
Ik kwam net dit tegen in mijn interessante-link-repository, misschien kan je er iets mee.

[ Voor 47% gewijzigd door sig69 op 21-04-2005 15:23 ]

[Verwijderd]

En het moet zeker ook crossbrowser zijn

[kakanox]

sig69 schreef op donderdag 21 april 2005 @ 15:21:
Op mij komt het allemaal erg vaag over.
We willen een datbase uitlezen, op een share waar we geen admin rechten hebben (maar wel htmlfiles kunnen dumpen?) en het liefst in een internet explorer venster via een applicatie maar zonder webserver...

Over moeilijk doen gesproken...

Edit:
Al die omwegen die je aan het verzinnen bent zijn alleen maar lapmiddelen. Als je applicatie echt nodig is moet je het gewoon hogerop zoeken en erdoor laten drukken dat je sysadmin het jou mogelijk maakt je werk te doen.

Edit2:
Ik kwam net dit tegen in mijn interessante-link-repository, misschien kan je er iets mee.

Moeilijk doen, lapmiddelen, inderdaad. Ik moet het doen met lapmiddelen, heb de keus niet. Dat heb ik helemaal bovenaan al aangegeven.

Met die laatste link... kan ik misschien wel iets! Bedankt!

[Verwijderd]

HTA is dus niet crossbrowser, zeg het even, vroeg het niet voor niets namelijk

[sig69]

Verwijderd schreef op donderdag 21 april 2005 @ 16:16:
HTA is dus niet crossbrowser, zeg het even, vroeg het niet voor niets namelijk

Dit is GEEN vraag:

Verwijderd schreef op donderdag 21 april 2005 @ 15:28:
En het moet zeker ook crossbrowser zijn

[kakanox]

het hoeft alleen maar op MSIE 6.0.2800.1150 te draaien. We mogen nl. ook geen andere browser installeren, en dat maakt het wel weer grappig

ze zijn hier nogal bang voor veranderingen.. is allemaal al zo gammel als wat, dus je krijgt bijna nergens toestemming voor.

[Verwijderd]

sig69 schreef op donderdag 21 april 2005 @ 16:18:
[...]

Dit is GEEN vraag:

[...]

Modbreak:

*wat gemompel over een TR i.p.v. offtopic geblaat*

[ Voor 20% gewijzigd door Creepy op 22-04-2005 11:44 ]

[kakanox]

Modbreak:

Meld dat liever even via een TR

[ Voor 78% gewijzigd door Creepy op 22-04-2005 11:45 ]

[farlane]

50 gebruikers op 1 access database is vragen om nog meer lapmiddelen

[kakanox]

dat is heel erg afhankelijk van hoeveel ze erin te doen hebben, niet?

[curry684]

kakanox schreef op vrijdag 22 april 2005 @ 10:23:
het hoeft alleen maar op MSIE 6.0.2800.1150 te draaien. We mogen nl. ook geen andere browser installeren, en dat maakt het wel weer grappig

Ja duh, ooit op een dag gaat er wel geupgrade worden. En dan kan je app er maar beter klaar voor zijn.

farlane schreef op vrijdag 22 april 2005 @ 11:21:
50 gebruikers op 1 access database is vragen om nog meer lapmiddelen

Afhankelijk van de load is dat best wel dodelijk ja...

[kakanox]

curry684 schreef op vrijdag 22 april 2005 @ 11:47:
[...]

Ja duh, ooit op een dag gaat er wel geupgrade worden. En dan kan je app er maar beter klaar voor zijn.

[...]

Afhankelijk van de load is dat best wel dodelijk ja...

de load blijft vrij laag, al is de groei in medewerkers hierop natuurlijk ook van invloed... ben benieuwd. wat raden jullie voor een database aan dan?

ennuhm... die app moet binnen MSIE blijven draaien. Lijkt me niet dat ze zomaar standaarden gaan depreciëren.

[kakanox]

Tip: als het uitkomt op een applicatie die op een share staat en via de share een Access DB gaat benaderen dan kan ik daar kort in zijn: Ja dat kan en er zijn tutorials die dat voor je uitleggen

Hey, is deze achteraf aangepast? Heb deze post nooit gezien! Of iig, nooit goed gelezen

Wat ik wil is letterlijk: Een applicatie die niet geïnstalleerd hoeft te worden maar wel een database aanspreekt. Het liefst heb ik: geen Windows-executables, alleen wat losse scripts en een databasefile. Portabiliteit zou een stuk verhoogd zijn als ik gebruik zou kunnen maken van een of ander in een internet explorer-venster.
Er moet de mogelijkheid zijn tot het weergeven van persoonlijke gegevens: Een soort login is dus een vereiste. Alles waarvoor ik toestemming moet vragen werk ik liever omheen, omdat dit het project nogal zal vertragen.

Als target kan je rekenen met 15-20 intensieve gebruikers.

P.S.: Ik ben dus NIET op zoek naar antwoorden als: "misschien kan je toch maar beter een executable bouwen en die installeren", hooguit "als je toestemming vraagt voor dit, zijn dat en dat de mogelijkheden". Dank U.

[ Voor 29% gewijzigd door kakanox op 22-04-2005 12:20 ]

[faabman]

Waarom host je de hele bende eigenlijk niet op een externe webserver die je via IP-filtering oid afschermd? Dan kun je gebruik maken van de functionaliteiten van IIS, de beveiliging is redelijk tot goed (en wanneer jij bij een goede partij host kun je zelfs behoorlijk stevig laten beveiligen). Eventueel kunnen extern werkenden ook nog bij je content, etc.

[stp_4]

faabman schreef op vrijdag 22 april 2005 @ 12:57:
Waarom host je de hele bende eigenlijk niet op een externe webserver die je via IP-filtering oid afschermd? Dan kun je gebruik maken van de functionaliteiten van IIS, de beveiliging is redelijk tot goed (en wanneer jij bij een goede partij host kun je zelfs behoorlijk stevig laten beveiligen). Eventueel kunnen extern werkenden ook nog bij je content, etc.

Ik zou er niet aan moeten denken om bedrijfsgevoelige informatie bij een extern hostingbedrijf onder te brengen. Interne informatie zou ik lekker intern houden.

[kakanox]

stp_4 schreef op vrijdag 22 april 2005 @ 12:59:
[...]

Ik zou er niet aan moeten denken om bedrijfsgevoelige informatie bij een extern hostingbedrijf onder te brengen. Interne informatie zou ik lekker intern houden.

Je was me net voor, maar ik had het ook niet beter kunnen verwoorden

[sig69]

faabman schreef op vrijdag 22 april 2005 @ 12:57:
Waarom host je de hele bende eigenlijk niet op een externe webserver die je via IP-filtering oid afschermd? Dan kun je gebruik maken van de functionaliteiten van IIS, de beveiliging is redelijk tot goed (en wanneer jij bij een goede partij host kun je zelfs behoorlijk stevig laten beveiligen). Eventueel kunnen extern werkenden ook nog bij je content, etc.

Dat zal waarschijnlijk ook wel niet mogen, als ze intern al zo moeilijk doen..

[BertS]

Als jij
* Geen webserver (die dus helemaal niet vanaf internet beschikbaar hoeft te zijn, maar alleen op het LAN) mag installeren op een centrale pc/server
* Geen executables op de clients wilt/kunt plaatsen

ben ik bang dat je weinig kunt doen, want óf die webserver, óf die exe moet de db aanspreken.

[curry684]

kakanox schreef op vrijdag 22 april 2005 @ 12:13:
[...]

de load blijft vrij laag, al is de groei in medewerkers hierop natuurlijk ook van invloed... ben benieuwd.

Access is niet bedoeld voor concurrent use, punt.

wat raden jullie voor een database aan dan?

http://www.microsoft.com/sql/msde/

ennuhm... die app moet binnen MSIE blijven draaien. Lijkt me niet dat ze zomaar standaarden gaan depreciëren.

Tenzij jij je site zo brak hebt gebouwd dat ie alleen toevallig onder IE6 leuk draait en onder IE7 per ongeluk niet meer.

Doe jezelf geen pijn, de enige standaarden die tellen zijn die van W3C. Dat het onder een heel specifieke versie van IE6 verder leuk eruit ziet boeit geen hol.

[BertS]

curry684 schreef op vrijdag 22 april 2005 @ 13:49:
[...]

Access is niet bedoeld voor concurrent use, punt.

[...]

http://www.microsoft.com/sql/msde/

Als je het over 15-20 users hebt zal Access waarschijnlijk beter performen dan MSDE.
In SQL Server 2005 Express is het perfomance-nadeel van MSDE verholpen

[kakanox]

curry684 schreef op vrijdag 22 april 2005 @ 13:49:
Doe jezelf geen pijn, de enige standaarden die tellen zijn die van W3C. Dat het onder een heel specifieke versie van IE6 verder leuk eruit ziet boeit geen hol.

HTA? komt dat al voor in de W3C?

[mbrouwer]

bee-es schreef op vrijdag 22 april 2005 @ 13:39:
ben ik bang dat je weinig kunt doen, want óf die webserver, óf die exe moet de db aanspreken.

Is niet helemaal waar het is wel mogelijk om via een HTA applicatie een DB aan te spreken, zelfs al is het een Access DB.

Mijn voorkeur zou in deze situatie toch wel uitgaan naar een XP of 2000 Pro met IIS en MSDE, kun je mooie ASP(.NET) applicaties op schijven en de machine hoeft niet eens in het domein te hangen, dus geen last van SysOps die niet willen dat je software gaat installeren.

[curry684]

bee-es schreef op vrijdag 22 april 2005 @ 13:52:
[...]

Als je het over 15-20 users hebt zal Access waarschijnlijk beter performen dan MSDE.

Vanaf 5 concurrent users is Access een ramp. En hij heeft het over 50 users

[Verwijderd]

Ik zou het ook gewoon een VB progje maken dat gegevens uit een MDB leest en een html genereerd.
De tweede optie dat dat progje moet hebben is dat hij html pagina's kan lezen.

Ik denk dat dit zo gepiept is omdat:
- webbrowser kant en klaar als module in vb6 zit.
- Je een mdb makkelijk met vb6 kunt uitlezen.
- Je makkelijk een txt file kunt maken met een .html extensie waar je html code in propt met je mdb gegevens.

[sig69]

curry684 schreef op vrijdag 22 april 2005 @ 14:05:
[...]

Vanaf 5 concurrent users is Access een ramp. En hij heeft het over 50 users

Niet dat ik voor acces ben hoor, maar er is wel een verschil tussen "5 concurrent users" en "50 users" natuurlijk.

Edit:
@bee-es: je hebt gelijk, ik reageerde puur op de post van cury684

[ Voor 19% gewijzigd door sig69 op 22-04-2005 14:16 ]

[BertS]

curry684 schreef op vrijdag 22 april 2005 @ 14:05:
[...]

Vanaf 5 concurrent users is Access een ramp. En hij heeft het over 50 users

Hier: [rml]kakanox in "[ VB6/HTML] Webbased database bouwen zónd..."[/rml] heeft hij het over 15-20

[curry684]

sig69 schreef op vrijdag 22 april 2005 @ 14:10:
[...]

Niet dat ik voor acces ben hoor, maar er is wel een verschil tussen "5 concurrent users" en "50 users" natuurlijk.

Absoluut, maar dat kunnen we met de gegeven info niet afleiden. Als de applicatie de callflow regelt voor een callcenter van 50 medewerkers zal het al snel continu 25 concurrent users betreffen, als het enkel de urenregistratie doet die iedere medewerker eenmaal daags bijwerkt is het 1 concurrent user, soms bij pech 2. Tevens belangrijk om te weten is de grootte van de database, daar het hele probleem van Access juist is dat voor iedere scheet de hele MDB over het netwerk gerukt wordt. Als je dat met een DB van 100Mb op een 100Mbit netwerk doet wordt je daar niet blij van, of je nu met 1 of 10 concurrent users zit.

Maja eigenlijk is de hele discussie gewoon academisch, omdat topicstarter gewoon tegen z'n opdrachtgevers moet zeggen dat het een stel idioten zijn als ze een webapp zonder webserver willen. Lokaal miniwebserver installeren op iedere bak is geen werkzame oplossing, dan moet je gewoon een rich client-app bouwen en die op iedere bak zetten. Beetje extreem geval 'buzzwordhype' lijkt het me zo als ik de uitleg lees, iemand heeft ooit gehoord dat webapps cool zijn en dus moeten ze het ook hebben, maar vervolgens weigeren ze de consequenties te accepteren dat je daar een webserver met client-server DBMS bij nodig hebt.

[sig69]

curry684 schreef op vrijdag 22 april 2005 @ 14:19:
[...]
Maja eigenlijk is de hele discussie gewoon academisch, omdat topicstarter gewoon tegen z'n opdrachtgevers moet zeggen dat het een stel idioten zijn als ze een webapp zonder webserver willen.
*knip*

Absoluut mee eens!

[kakanox]

curry684 schreef op vrijdag 22 april 2005 @ 14:19:
[...]

Absoluut, maar dat kunnen we met de gegeven info niet afleiden. Als de applicatie de callflow regelt voor een callcenter van 50 medewerkers zal het al snel continu 25 concurrent users betreffen, als het enkel de urenregistratie doet die iedere medewerker eenmaal daags bijwerkt is het 1 concurrent user, soms bij pech 2. Tevens belangrijk om te weten is de grootte van de database, daar het hele probleem van Access juist is dat voor iedere scheet de hele MDB over het netwerk gerukt wordt. Als je dat met een DB van 100Mb op een 100Mbit netwerk doet wordt je daar niet blij van, of je nu met 1 of 10 concurrent users zit.

Maja eigenlijk is de hele discussie gewoon academisch, omdat topicstarter gewoon tegen z'n opdrachtgevers moet zeggen dat het een stel idioten zijn als ze een webapp zonder webserver willen. Lokaal miniwebserver installeren op iedere bak is geen werkzame oplossing, dan moet je gewoon een rich client-app bouwen en die op iedere bak zetten. Beetje extreem geval 'buzzwordhype' lijkt het me zo als ik de uitleg lees, iemand heeft ooit gehoord dat webapps cool zijn en dus moeten ze het ook hebben, maar vervolgens weigeren ze de consequenties te accepteren dat je daar een webserver met client-server DBMS bij nodig hebt.

Oh so right.. maar dat verandert de situatie niet :-) ik kan nog steeds eigenlijk geen applicatie draaien.
En 20 intensieve users... Ik denk niet dat ik meer dan 2-3 concurrent users ga tegenkomen. Heel wat verschil tussen intensief en concurrent..

[BertS]

curry684 schreef op vrijdag 22 april 2005 @ 14:19:daar het hele probleem van Access juist is dat voor iedere scheet de hele MDB over het netwerk gerukt wordt. Als je dat met een DB van 100Mb op een 100Mbit netwerk doet wordt je daar niet blij van, of je nu met 1 of 10 concurrent users zit.

offtopic:
Valt wel mee hoor. Een jaar geleden heb ik het eens getest, met een Access-db van 1Gb en een frontend op een andere lokatie, over een VPN-lijntje (max snelheid 512kb).
Met 'gekoppelde tabellen' naar een Access-frontend werkte dat niet echt lekker, maar het was wel te doen. In sommige gevallen zou het wellicht zelfs acceptabel zijn voor end-users, maar dat geldt uiteraard niet als je er de hele dag in moet werken. (voor bijv. die urenadministratie vanaf thuis bijv, zou het nog wel kunnen denk ik).
Ook heb ik het toen geprobeerd door netjes met ADO te werken, en dat werkte uitstekend!!
En de snelheid waarmee dat werkte maakte mij iig wel duidelijk dat jouw statement van hierboven niet waar is

[curry684]

bee-es schreef op vrijdag 22 april 2005 @ 14:37:
[...]

Ook heb ik het toen geprobeerd door netjes met ADO te werken, en dat werkte uitstekend!!
En de snelheid waarmee dat werkte maakte mij iig wel duidelijk dat jouw statement van hierboven niet waar is :+[/small]

ADO cachet lokaal, wat bij veranderlijke data met meerdere concurrent users natuurlijk nog steeds geen reet opschiet Voor grote blokken redelijk statische data scheelt het natuurlijk wel een slok op een borrel

[kakanox]

bee-es schreef op vrijdag 22 april 2005 @ 14:37:
[...]

offtopic:
Valt wel mee hoor. Een jaar geleden heb ik het eens getest, met een Access-db van 1Gb en een frontend op een andere lokatie, over een VPN-lijntje (max snelheid 512kb).
Met 'gekoppelde tabellen' naar een Access-frontend werkte dat niet echt lekker, maar het was wel te doen. In sommige gevallen zou het wellicht zelfs acceptabel zijn voor end-users, maar dat geldt uiteraard niet als je er de hele dag in moet werken. (voor bijv. die urenadministratie vanaf thuis bijv, zou het nog wel kunnen denk ik).
Ook heb ik het toen geprobeerd door netjes met ADO te werken, en dat werkte uitstekend!!
En de snelheid waarmee dat werkte maakte mij iig wel duidelijk dat jouw statement van hierboven niet waar is

da's niet offtopic, da's best interessante info! ik ga even een tutorial over HTA zoeken denk ik.. ken het nog niet zo goed.

[BertS]

curry684 schreef op vrijdag 22 april 2005 @ 14:44:
[...]

ADO cachet lokaal, wat bij veranderlijke data met meerdere concurrent users natuurlijk nog steeds geen reet opschiet Voor grote blokken redelijk statische data scheelt het natuurlijk wel een slok op een borrel

Ik wilde dan ook alleen maar aantonen dat jouw opmerking, over het overtrekken van de hele database, niet correct is
Uiteraard ben ik het met je eens dat een Access-database meer traffic genereert dan een C/S-database, maar daarom hoef je Access nog niet direct aan de kant te gooien

[kakanox]

bee-es schreef op vrijdag 22 april 2005 @ 15:31:
[...]
Ik wilde dan ook alleen maar aantonen dat jouw opmerking, over het overtrekken van de hele database, niet correct is
Uiteraard ben ik het met je eens dat een Access-database meer traffic genereert dan een C/S-database, maar daarom hoef je Access nog niet direct aan de kant te gooien

hier ligt een gigabit netwerk.. netwerkstations allemaal Pentium 4's van tussen de 2.6 en 3.0 GHz
(800 MHz FSB).. Allemaal 504MB RAM (512 -/- 8MB shared video)... Server is ook geen kleine jongen.

beetje load is geen ramp hier hoor..

[BertS]

kakanox schreef op vrijdag 22 april 2005 @ 15:38:
beetje load is geen ramp hier hoor..

Dat je de ruimte hebt wil natuurlijk niet zeggen dat je ook álles móet gebruiken he

[sig69]

Precies. Stel dat alle game developpers er ook zo over dachten, dan draaiden we nu nog Doom op onze P4's...

[kakanox]

klopt, maar het is weer 1 barriere minder.. jullie willen mooie graphics en niet op de tv, dus heb je een snelle videokaart nodig. zo werkt het hier ook..