Hintergrund: Ich habe eine Access-Software (~30 gleichzeitige Benutzer) mit geteiltem Front- und Backend, sowohl UI als auch DB, die auf Access-Dateien laufen. Die wichtigsten Funktionen für mich sind Berichte und Drucken, mit Schwerpunkt auf schneller Entwicklung und Bereitstellung für die Benutzer (Updates 1-3 mal pro Woche, mit so wenig Zeitaufwand wie möglich). Die Umgebung ist Win7 + Access 2010. Updates werden mit .BAT-Batch-Datei behandelt. Die Datenbank wird möglicherweise später in diesem Jahr auf SQL Server Express oder etwas anderes aktualisiert.
Probleme: Die Access-Entwicklungsoberfläche wird langsam, hauptsächlich aufgrund von verknüpften Datenbanktabellen, bei denen es sich um Dateien handelt, die sich auf Netzlaufwerken (und einer Sharepoint-Liste) befinden. Mir ist auch bewusst, dass Access keine ideale Datenbank für Mehrbenutzer-Sachen ist. Dann gibt es kosmetische Dinge wie das Ausblenden des Hauptzugriffsfensters. Ich habe Code dafür, der in WinXP großartig funktioniert, aber in Win7 bleibt der Hintergrund nicht mehr verborgen. Insgesamt ist die ganze Software nicht sehr professionell.
Was ich brauche: Ich muss in der Lage sein, eine schnelle Entwicklung und Bereitstellung ohne Administratorrechte in einer Windows 7-Umgebung durchzuführen. Clients müssen in der Lage sein, ihre Benutzeroberfläche mit minimalem (wenn überhaupt) Aufwand zu aktualisieren, was bedeutet, dass keine Installationsprogramme für sie erforderlich sind.
Offensichtlich könnte Visual Studio der logische nächste Schritt sein, aber ich habe so wenig Erfahrung damit, dass ich nicht weiß, wie schnell die Entwicklung dort sein kann? Dann habe ich von Dingen wie AppJS gehört, aber funktioniert das gut mit Geräten (Druckern)? Außerdem sind alle Daten vertraulich, also sollte alles ohne externe Server und Abhängigkeiten funktionieren (zukünftiger Datenbankserver wird im Gebäude stehen). Ansonsten würde ich eine Webbrowser-Umgebung lieben, da sie von überall verwendet und entwickelt werden könnte.
Welche Möglichkeiten habe ich und warum, oder sollte ich bei MS Access bleiben?
[Bearbeiten Nr. 1] Clientseitiges Javascript Es scheint eine Option zu sein, clientseitiges Javascript auszuführen und es zum Herstellen einer Verbindung mit SQL Server zu verwenden. Ich höre jedoch, dass dies zwar möglich, aber aufgrund der Sicherheitsbedenken auch eine schlechte Vorgehensweise ist. Während unsichere Verbindungszeichenfolgen und Quellcode kein großes Problem bei der internen Verwendung in Unternehmen darstellen, ist dies dennoch etwas, was die IT-Regeln des Unternehmens möglicherweise nicht zulassen. Auch die UI-Entwicklung wäre nicht so schnell wie mit Access, obwohl es immer noch großartig ist, wenn man mit JS vertraut genug ist. Ich werde wahrscheinlich einige Prototypen damit ausprobieren.
[Edit #2] 8 Jahre später wollte ich nur für andere Leser sagen, dass wir die Datenbank auf SQL Server migriert haben und es reibungslos gelaufen ist. Derzeit verwenden wir das neueste MS Access als Benutzeroberfläche und SQL Server 2019 als Backend-Datenbank mit einigen verschlüsselten Spalten. Später werden wir zur Azure-Datenbank migrieren. Neue Anwendungen verwenden hauptsächlich PowerApps in Office365 mit Sharepoint-Listen als Datenbank (auch mit der Möglichkeit, auf SQL Server zu migrieren). Sehr empfehlenswert.
Vielleicht nicht die beste Lösung überhaupt, aber gemessen am Aufwand die günstigste, ist die Umstellung Ihrer Access-Datenbank auf SQL Server , am besten auf Microsoft SQL Server.
In Microsoft Access '97 und 2000 gab es sogar ein Tool namens Upsizing Wizard , das genau das tat.
Wichtigste Fakten:
MS SQL Server ist kostenlos, bis er auf einem einzelnen CPU-Kern läuft und bis er nicht verwendet wird, um seine Verbindungen zu Benutzern außerhalb des Unternehmens (zu Clients) bereitzustellen, dh in Form von Hosting-Diensten. Es bleibt unter den gleichen Bedingungen kostenlos, wenn Sie die Client-Server-Lösung an jemand anderen verkaufen.
Der Übergang zu MS SQL Server ist der kleinste Bruch (wenn Sie von Microsoft Access migrieren), Änderungen in Ihrem vorhandenen SQL-Code sind minimal. Es können auch andere SQL-Server verwendet werden, aber die "Code-Distanz", die Sie überwinden müssen, ist größer.
Grundsätzlich können Sie Ihre Access-Client-Apps unverändert lassen, außer dass Sie die Verbindungszeichenfolge ändern und inkompatible SQL-Befehle anpassen
Später können Sie Ihre Client-App neu schreiben.
Der Punkt ist, dass Sie nicht gleichzeitig auf Client- und Serverseite in große Veränderungen gedrängt werden.
Ich bin diesen Weg mit einer Anwendung vor ungefähr 12 Jahren gegangen (es war Access'97, SQL Server 2000). Wir haben zuerst die Daten migriert, einige Monate später entschied sich der Kunde, die Clients neu zu schreiben. Es standen keine ernsthaften Hindernisse im Weg.
Seitdem habe ich eine gut geschriebene große professionelle Unternehmens-Webanwendung gewartet/erweitert, jetzt schreibe ich wieder binäre Clients mit klassischen Fenstern und Formularen. Mein subjektives Ergebnis ist, dass die Entwicklungsproduktivität bei Webanwendungen geringer ist (Browserkompatibilitätsprobleme, unwillkommene Zurück - Schaltfläche im Browser, schwierigeres Debugging, UI-Steuerelemente sind sehr begrenzt), teilweise übergewichtet durch eine bessere Zugänglichkeit, die Sie erreichen können (sofern die Browser dies zulassen). Meine subjektive Meinung wäre also, NICHT den Weg der Web-App zu gehen, da Sie möglicherweise viel mehr Energie benötigen, um vergleichbare Ergebnisse zu erzielen. Aber wenn Sie sich schon dafür entschieden haben, wünsche ich Ihnen trotzdem viel Glück mit Ihrer neuen App.
Zu Ihrer Forderung nach "sehr schneller Entwicklung": Ich glaube, dass es für sehr kleine Lösungen möglich ist. Für größere müssen Sie Ihre Grundlagen sorgfältig schreiben (es sei denn, Sie sind ein Copy-Paste-Programmierer), um die wachsende Komplexität Ihrer App zu bewältigen. Sie zu schreiben hat oft nichts mit "schneller Entwicklung" zu tun, da das Legen solider Grundlagen nicht sofort neue Bildschirme, Funktionalitäten oder andere Ergebnisse hervorbringt. Ich habe eine App gesehen, die weitgehend mit Rapid Development geschrieben wurde, aber jetzt wartet sie auf eine Überarbeitung, weil die Code-Vernunft „schnellen Ergebnissen“ geopfert wurde und Sie denselben Code mit geringfügigen Änderungen 100 Mal kopiert und eingefügt finden werden. Es ist die Hölle des Programmierers, sehr schwer zu pflegen. (Wenn ein solcher Code geändert oder behoben werden muss, müssen Sie ihn auf 100 Stellen anwenden.)
Kaleb
Stackmerre
Kaleb
Stackmerre