Hallo,
meine Anwendung hat die Daten in ein My-Sql DB.
Die Anwendung selber ist in Acc wobei die Zugriffe auf die SQL-Db immer mit SQL-String geschieht.
Jetzt kommt die Frage ob man dieses nicht Web fähig machen kann.
Hat da jemand Erfahrung?
Gruß
Johann
Hallo,
Es geht schon....
... aber von Formularen und Berichten im bekannten Sinne kann man sich dann verabschieden.
Andere Option ist per IP im INET zugängliche MS SQL Server. Mit dem kann man sich sowohl von Access als auch von Scriptsprachen wie PHP verbinden. Hatte ich einmal gemacht für einen Webshop mit Access Admin-Backend. Letzteres war als Access Projekt (ADP) ausgeführt, der Webshop ist mit PHP gemacht. Soweit ich weiss läuft das auch heute noch so (DVD Verleih in der Schweiz).
Gruß Andreas
Hallo,
Zitat...ob man dieses nicht Web fähig machen kann
Wobei sich auch die Frage aufdrängt, was du unter 'webfähig' verstanden haben willst. :-\
Soll das in Form von 'Internetseiten' passieren - möglicherweise in weitestem Sinne jeglicher Formen von Webshops (maß ja nicht immer mit Handel zu tun haben) - dann bietet
sich der Vorschlag von Hondo generell an, weiter gäbe es die Möglichkeit einer ODBC Anbindung für ASP-Seiten (ASP 3.0) in Verbindung mit dem MySQL-Backend wobei hier die Access-Frontends wegfallen.
Allerdings bedingt dieses wiederum den Betrieb eines Webservers im öffentlichen Adressraum - gleiches gilt für PHP-Lösungen.
Soll es darum gehen, 'lediglich' das Backend via I-Net zu erreichen um verteilte Access-Frontends mit Daten zu versorgen würde es m.E. genügen das Backend 'erreichbar' zu machen.
D.h. deine MySQL DB muss auf einem Rechner liegen, der unterbrechungsfrei über eine öffentliche IP-Adresse erreichbar ist. Frontends können dann per ODBC auf ihr Backend zurückgreifen.
Wo der Rechner lokalisiert ist bleibt sich gleich, es muss eben nur gewährleistet sein, dass sich die IP nicht ändert - dass also KEIN 'Otto-Normalverbraucher-',
sprich privater Internetzugang, mit wechselnden IP-Adressen die Anbindung des Backends ans Internet herstellt.
Die Datenzugriffe auf das Backend erfolgen in diesem Fall Ad hoc und sind per VBA ausprogrammiert - zu beachten ist bei der Entscheidung ob permanent eine Verbindung bestehen muss oder soll die Häufigkeit der Zugriffe und die verfügbare Bandbreite in Hinblick auf den zu erwartenden Datenverkehr. Das 'linken' von Tabellen übers Internet würde ich selbst aber ausschließen.
Im Zusammenhang mit dem MS SQL-Server kann deine Überlegung in die Richtung ADP (Access Data Project) gehen, wobei du dann (fast) die ganze Funktionspalette
des MS SQL-Servers in den Frontends nutzen kannst. Die Verwendung von ADPs zusammen mit MySQL ist nicht möglich - zumindest habe ich noch nirgends eine solche
Konstellation gesehen oder von einer funktionierenden gehört oder gelesen.
HTH
Hallo Andreas und Peter,
erstmal vielen Dank für die Beiträge. Jetzt bin ich schon mal schlauer geworden.
Jetzt muss ich erstmal überlegen ob es sich wirklich rechnet davon eine Internet-Geschichte zu machen.
Der Aufwand ist auf jedenfall recht hoch.
Da Ihr ja im positiven Sinne immer neugierig seit hier noch den Hintergrund:
Das Ganze ist eine Güllebörse mit Vermittlung der Gülle, Lieferscheinschreibung vom Landwirt zur Börse und von der Börse zum Landwirt.
Der wirklich schwierige Teil ist aber die Berechnung von Natrium, Phosphor und Kalium in der Gülle.
Das wird dann noch mit dem Abgeglichen was der einzelne Landwirt aufnehmen darf. Hängt wirderum mit Vieh und
Fläche zusammen.
Jetzt kam die Überlegung das die einzelnen Landwirte ihren Viehbestand und die Flächen selber einpflegen können.
Im Gegenzug würden diese dann den sogannten QFN (Qualifizierter Flächennachweis) bekommen.
Das kleinste Problem ist der Internetzugang der Landwirt. Es ist halt nicht so wie bei Bauer sucht Frau. Der Landwirt
heute brauch ca ein viertel seiner Arbeitszeit für Büroarbeit. Viele haben sogar ein eigenes Netzwerk vom Büro zu den Ställen.
Gruß
Johann
Hallo,
das hört sich ja ziemlich geruchsintensiv an ;D :D ;D
Zitat...ob es sich wirklich rechnet davon eine Internet-Geschichte zu machen
Kommt darauf an, wieviele 'Kunden' du zu betreuen hast.
Einen schlanken Fuß macht - auch auf den vielleicht erwarteten Werbeeffekt - eine Internetlösung allemal.
Also im weitesten Sinne ein Webshop mit Anmeldung, Bedarfsmeldung, Abruf, Lieferterminen, und, und, und ...
Selbst wenn du keinen Webshop ins Auge faßt bleibt die Notwendigkeit der ununterbrochenen Erreichbarkeit des Backends bestehen.
Ob du das nun mit MySQL, MS SQL-Server oder notfalls einer Access-Datenbank löst bleibt deiner Entscheidung, dem Datenaufkommen und deinem technischen Vermögen vorbehalten.
Bin gespannt, vielleicht meldest du dich ja mit der einen oder anderen Frage zum Projekt wieder bei uns im Forum und/oder stellst uns im Fall einer Weblösung mal das Produkt zur Ansicht vor. ;)
Ich wünsch' dir auf jeden Fall schon mal den richtigen 'Riecher' :D :D
Hallo Peter,
vielen Dank für die Antwort.
Dieses Jahr werde ich mich zwar weiter damit beschäftigen aber noch keine Entscheidung treffen.
Hab einfach noch zu viele andere Sachen die fertig müssen (wie jedes Jahr).
Auf jeden Fall kann ich sagen das ich mit Scheisse (Entschuldigung heißt aber so) schon einiges an Geld verdient habe.
Und das ohne jemand zu benachteiligen.
Ich melde mich auf jeden Fall wie es ausgeht.
Die fertige Lösung werde ich nicht präsentieren können, da zu viele Daten sensibel sind.
Auch das wird noch eine Herausforderung die Sache einbruchssicher zu machen.
Gruß
Johann
Hallo,
eine Alternative wäre auch den EDV-Landwirten ein Frontend zu geben, wo sie Ihre Meldungen machen und diese letztlich per Email an dich verschickt wird.
Bei dir im Admin-System werden dann z.B. bei Programmstart oder nach best. Zeit der Posteingang nach neuen Meldungen durchsucht und automatisch importiert. Das sollte mittels Outlook-Automatisation kein Problem darstellen, musst nur für eindeutige Identifizierung der Mail sorgen damit diese erkannt wird.
Andreas
Hallo,
:D ;D :D
Geld stinkt ja bekanntlich auch dann nicht, wenn's mit Scheiße verdient wird...
ZitatAuch das wird noch eine Herausforderung die Sache einbruchssicher zu machen
Zugangsbeschränkung per SQL-Authentifizierung auf SQL Server, bzw. Benutzerauthentifizierung auf MySQL
Die Benutzernamen mußt du vorab an die Kunden vergeben und NICHT hardcoden!
Jeder
erste Zugriff sollte authentifiziert werden, wobei dann die Kennung solange am aktiven Frontend gespeichert bleibt, bis die Sitzung abgemeldet wird.
Die Beschränkung auf IP bezogen wie sie MySQL anbietet würde ich ausschließen (auch bei Kunden mit fixer IP-Adresse)