Ik neem aan dat je op zijn minst een back-up wil maken, dus die DB moet even down. Voor zover ik weet kan je 'Comprimeren en Herstellen' alleen via de applicatie zelf doen. Dan moet je dus eerst de DB downloaden of via remote desktop op de server beheren. Er is geen simpele manier om een Access DB remote bij te werken via een client. (Zoals een echte server op een vaste poort draait.)
Tenzij je niet kunt converteren naar een DBMS dat je hoster heeft. En ja, waarschijnlijk is dat wel MySQL (minimaal) maar toch.
In dit geval kan zelfs SQLLite e.d. nog sneller zijn vrees ik. En als de hoster geen MySQL/MSSQL doet tja, dan is het misschien tijd om een echte hoster te zoeken.
Tja, dat is aan TS... ik baseer me iig een klein beetje op:
Voor zover ik begreep is het forum dat hij gebruikt wel enigzins cross-DBMS. Als dat niet het geval is is het inderdaad spijtig en zijn we te laat want dan had de vraag misschien bij oprichting al moeten worden gesteld.
En waarin verschilt dat met enig ander DBMS?
Dat een 'back-up' van een echte DBMS puur de data bevat en niet de indices en andere ondersteunende informatie.
Dat een 'typmiep' een DB bij elkaar klikt of dat je een kant-en-klare DB gebruikt van een kant-en-klaar product; lijkt me nogal een verschil. En true, die laatste is mischien ook niet 100% geweldig van opzet. Maar kom op...
In dit geval is het gewoon gebrek aan inzicht bij de ontwikkelaar. Tenzij het niet de bedoeling was dat er meer dan 100 users op het forum kunnen. Maar dan wil ik ook graag een keiharde 'maximum number of users reached' geïmplementeerd zien. Zolang dat in 99% van de gevallen niet gebeurd, blijven we met DWTF's strooien.
Comprimeren lukt met MSSQL én MySQL DB's doorgaans ook best aardig, met dezelfde ratios. Is dat een argument?
Zie voorgaand.
Voor mij is het net zo glashelder, maar niet zo zwart-wit. Ik heb écht geen trek om MSAccess hier met hand-en-tand te gaan zitten verdedigen, want zo geweldig is het niet. Ik zeg alleen dat je best wat kunt nuanceren.
Bij mij is het gewoon over met een dergelijk gedoogbeleid. Ja dat is vrij zwart-wit, maar op een gegeven moment moet je keuzes maken om verder te kunnen.
En waar baseer je op dat dat bij het product dat TS gebruikt zo is? Ken je het? Heb je het gebruikt? Ken je de 'inner workings'? Ik niet, dus ik doe geen zwart-witte uitspraken. Misschien kan 't ding wel overweg met 20 verschillende DB's en heeft TS (of een 'voorganger' of whatever) wel gekozen voor MSAccess omdat die 'bekend' was zonder verder goed geïnformeerd te zijn over de voor/nadelen. Misschien zit het best goed en 'knap' in elkaar. Who knows. Ik zeg alleen dat een 'paniek peeuw!' of 'code red' (in principe) nog lang niet aan de orde is en dat TS niet in blinde paniek over hoeft te stappen.
Het lijkt mij zeer onwaarschijnlijk dat het hier een multi DB-backend systeem betreft aangezien de meeste ontwikkelaars door o.a. de gebrekkige T-SQL implementatie het gewoon VER achter zich laten liggen. (Wat je zelf ook wel kan bedenken want van de noodzakelijke proxy layer gaat niemand opgewonden raken.) Access is technologie van 10 jaar geleden met inmiddels een legacy karavaan waar je onder de voet wordt gelopen door de bugs en quirks. Het is een slapend monster dat een gegeven moment toe slaat en al je tijd opeet.
Neen, met dergelijke mailware wil ik niet verder. En de code red lijkt mij nu nog een code yellow gezien de TS wel degelijk twijfels heeft bij de integriteit van zijn forum.
edit: het schijnt wel multi backend te zijn dus inderdaad. Ik zal het nog wel eens even uitzoeken want ik ruik een DWTF.
:strip_exif()/u/47978/crop614f3a5e62a21_cropped.gif?f=community)
:strip_icc():strip_exif()/u/43400/avatar.jpeg?f=community){kind=avatar}
Die's nieuw! 
:strip_icc():strip_exif()/u/32232/laupro60x60.jpg?f=community)
absoluut waar wat je zegt.