VB, Access, Client und Server...?

Hallöchen,

gibt es irgendwo gute (kompakte) Informationen oder Beispielprogramme wie eine Client-Server-Kommunikation per Visual Basic ablaufen muß, d. w. wie eine Verbindung ordnungsgemäß realisiert wird und wie man Benutzerzugriffe regelt?

Habe kaum Erfahrung in Office-Programmierung, deshalb stelle ich mir das bisher so vor, daß auf einem Rechner Access mit einer geöffneten Datenbank läuft und mehrere andere Rechner über ein internes Netzwerk ihre Anfragen an dieses Access schicken. Der muß dann die entsprechenden Schreib-, Leserechte vergeben bzw. den Zugriff gegebenen falls verweigern.

Ist der Ansatz vom Prinzip her richtig, oder gibt es da eine simplere Lösung?

Schönen Dank schonmal für alle Tips dazu,

Stephan

Hi,

gibt es irgendwo gute (kompakte) Informationen oder
Beispielprogramme wie eine Client-Server-Kommunikation per
Visual Basic ablaufen muß, d. w. wie eine Verbindung
ordnungsgemäß realisiert wird und wie man Benutzerzugriffe
regelt?

Nun ja: gut weiß ich nicht, aber kompakter gehtes wohl nicht:

Das geht nicht.

Access ist eine Desktop-Datenbank. Wenn Du unbedingt eine Client/Server-Anwendung programmieren möchtest, mußt Du auf eine „richtige“ Datenbank zurückgreifen, z.B. MS-SQL Server, Oracle oder MySQL.

Gruß

J.

hallo,

und danke erst mal für die Antwort, aber…

Ich dachte ich hätte im Netz schon ein paar Hinweise gefunden, daß mit Access auch eine art Intranet-Benutzung möglich sei. Aber vielleicht hab ich da was falsch verstanden…

Das hieße dann also, ich müßte einen mySQL-Server laufen lassen, der dann entsprechend die Anfragen verwaltet. Ich glaube, ich habe zu beidem (mySQL-server sowie die Verbindung zu Visual Basic) neulich auf irgend einer VB-Seite gesehen. Hoffentlich finde ich das wieder…) :smile:

Schönen Tag noch,

Stephan

hallo

access kann man für kleine intranetanwendungen mit wenig user schon benutzen.

eine client server lösung versteht man meistens eine 3-tier (und mehr) architektur… im MS umfeld könnte das etwa so aussehen:

  1. Tier --> Presentation : Win32 Client (z.b. VB) oder HTML
  2. Tier --> Business logic : MTS/COM+ oder WebServices
  3. Tier --> DataBase : SQLServer :smile:

Gruss
Giuseppe

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

access kann man für kleine intranetanwendungen mit wenig user
schon benutzen.

So hzatte ich die bisher gefundenen Infos im Netz auch interpretiert. Es geht im Prinzip auch um nicht mehr als drei oder vier Nutzer, die auf die Datenbank zugriff haben sollten.

eine client server lösung versteht man meistens eine 3-tier
(und mehr) architektur… im MS umfeld könnte das etwa so
aussehen:

  1. Tier --> Presentation : Win32 Client (z.b. VB) oder HTML
  2. Tier --> Business logic : MTS/COM+ oder WebServices
  3. Tier --> DataBase : SQLServer :smile:

Das ist ja alles schön und gut, aber gibt es für solche Problemstellungen keine (gescheiten) Dokus oder Beispielcode? Kann gerne auch in englisch sein.

Schönen Tag noch,

Stephan Huebner

Re^5: nicht optimal :smile:
also es gibt einige bücher:

http://www.amazon.de/exec/obidos/ASIN/386063626X/qid…

http://www.apress.com/book/supplementDisplay.html?bI…

gruss

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

das geht sehrwohl

Hi,

gibt es irgendwo gute (kompakte) Informationen oder
Beispielprogramme wie eine Client-Server-Kommunikation per
Visual Basic ablaufen muß, d. w. wie eine Verbindung
ordnungsgemäß realisiert wird und wie man Benutzerzugriffe
regelt?

Nun ja: gut weiß ich nicht, aber kompakter gehtes wohl nicht:

Das geht nicht.

Was soll dabei nicht gehen, abgesehen davon, daß ein ODBC-Zugriff ohnehin möglich ist, kann er die DB in einem freigegebenen Ordner betreiben und jeder kann darauf zugreifen. Über Gruppenrichtlinien kann er die Berechtigungen vergeben, ganz ohne MTS/COM+.

Access ist eine Desktop-Datenbank. Wenn Du unbedingt eine
Client/Server-Anwendung programmieren möchtest, mußt Du auf
eine „richtige“ Datenbank zurückgreifen, z.B. MS-SQL Server,
Oracle oder MySQL.

Access ist eine richtige Datenbank, die gerade für kleine Applikationen ideal ist, oder würdest Du Deine Kochrezeptesammlung auf einer ORACLE-DB verwalten?

Gruß

J.

lG

Wolfgang

Hi,

Beispielprogramme wie eine Client-Server-Kommunikation per
Visual Basic ablaufen muß, d. w. wie eine Verbindung
ordnungsgemäß realisiert wird und wie man Benutzerzugriffe
regelt?

Was soll dabei nicht gehen, abgesehen davon, daß ein
ODBC-Zugriff ohnehin möglich ist, kann er die DB in einem
freigegebenen Ordner betreiben und jeder kann darauf
zugreifen. Über Gruppenrichtlinien kann er die Berechtigungen
vergeben, ganz ohne MTS/COM+.

Lies sein Ursprungsposting, worauf sich auch meine Antwort bezog: er wollte Access in einer Client/Server-Umgebung eingesetzt bekommen, und das geht eben nicht.

Später hat er präzisiert, was er genau machen wollte. Da stimmme ich Dir zu (hab auch ein paar Jahre Access-DBs mit Netzwerkzugriff entwickelt, klar weiß ich, daß das möglich ist).

Access ist eine Desktop-Datenbank. Wenn Du unbedingt eine
Client/Server-Anwendung programmieren möchtest, mußt Du auf
eine „richtige“ Datenbank zurückgreifen, z.B. MS-SQL Server,
Oracle oder MySQL.

Access ist eine richtige Datenbank, die gerade für kleine
Applikationen ideal ist, oder würdest Du Deine
Kochrezeptesammlung auf einer ORACLE-DB verwalten?

Ja, unbenommen, für kleine Applikationen und was alles auch immer. Für Client/Server-Anwendungen, was die Frage war, eben nicht.

(Ich hoffe, Dir muß ich den Unterschied zwischen Desktop- und Serverdatenbanken nicht erklären).

Gruß

J.

stimme josé zu. o.t.
.

Empfehlung
Salü Stefan

Das beste deutschsprachige Buch für Client / Server Computing, was übrigens nur eine Trennung von Daten (DB) und GUI / Logik (Frontend) bedeutete, mit VB ist von Michael Kofler: „Datenbankprogrammierung“. Es eine für fortgeschrittene Programmierer eine komplette Einführung. Da VB Datenbankprogrammierung heute konsequent ADO bedeutet, wäre das nächste Werk "ADO 2.5 von William R. Vaughn Galileo Verlag. Dieser Verlag ist übrigens nahezu die vollständige Crew des deutschen Addison und Wesley Verlages, welcher betreffend Fachkompetenz immer einen guten Ruf hatte.

Meines erachtens solltest Du sehr sorgfältig abwägen, ob Du eine „Pseudo“ Datenbank wie Access oder MySQL nimmst, oder nicht doch gleich richtig mit SQL-Server oden einem OpenSource Product wie Ozelot, Progres oder SABDB greifst. Sobald Du über nw auf Daten zugreifst oder mehrere Benutzer hast, usw. sind der Ärger und der Aufwand wenn Probleme (Locking, korrupte DB, etc.) auftreten, den Einsatz einer Pseudo DB nicht wert.

Ich hoffe ich konnte Dir mit meiner Meinung etwas Licht in den Dschungel bringen :wink:
viele Grüsse
Peter

Hi,

Meines erachtens solltest Du sehr sorgfältig abwägen, ob Du
eine „Pseudo“ Datenbank wie Access oder MySQL nimmst

Sind das nicht völlig verschiedene Dinge in einen Topf geworfen?

Gruß

J.

Hi Josè

Hi,

Meines erachtens solltest Du sehr sorgfältig abwägen, ob Du
eine „Pseudo“ Datenbank wie Access oder MySQL nimmst

Sind das nicht völlig verschiedene Dinge in einen Topf
geworfen?

Gruß

Eine gute Frage. Wahrscheinlich eine Frage der Perspektive!

Meine Aussage zielt auf den Sachverhalt ab, dass ähnliche Gründe in der Winows Welt zum Einsatz von MS-Access führen, wie in der Linux Welt für MySQL.
Unter Windows nimmt man vielfach MS-Access, weil
-man kennt das UserInterface
-„geringe“ Office Lizenzkosten (quasi gratis)
-sehr gute Unterstützung durch Middleware (seit ODBC).
Unter Linux nimman vielfach MySQL, weil
-geringerer Lernaufwand als PostgreSQL oder Ozelot,
da geringer Komplexität (keine Sichten, keine Fremdschlüssel,
keine Stored-procedures/Trigger)
Mit wenig Grundlagenkenntnissen hat man schnell eine Datenbank.
-viele deutschsprachige Infos, Bsp. besonders im Zusammenhang
mit PHP

siehe auch:
http://www.mysql.de/documentation/mysql/bychapter/ma…
http://www.tbee.de/mysql/t5_mysql_vergleich.php

Es liesse sich wohl auch gut darüber streiten, ob Access seit DAO / Jet beerdigt sind, noch als eine Desktop DB zu bezeichnen ist… Eher wohl als SQL-Server light.

Grüsse Peter

Hallo Peter,

Meines erachtens solltest Du sehr sorgfältig abwägen, ob Du
eine „Pseudo“ Datenbank wie Access oder MySQL nimmst, oder
nicht doch gleich richtig mit SQL-Server oden einem OpenSource
Product wie Ozelot, Progres oder SABDB greifst. Sobald Du über
nw auf Daten zugreifst oder mehrere Benutzer hast, usw. sind
der Ärger und der Aufwand wenn Probleme (Locking, korrupte DB,
etc.) auftreten, den Einsatz einer Pseudo DB nicht wert.

Hört sich ja grausig an… :smile:

Ich hoffe ich konnte Dir mit meiner Meinung etwas Licht in den
Dschungel bringen :wink:

Etwas, auch wenn mich das gesagte eher abschreckt. Aber da es nun mal gemacht werden muß, werde ich mir jetzt erst mal mySQL genauer ansehen und danach die „richtigen“ Sachen. Wird jedenfalls echt heftig sich da reinzuarbeiten, fürchte ich…

Mit freundlichen Grüßen,

Stephan

Zutaten für grausig…
-instabiles NW (IP-Päcklein purzeln quer :wink: )
-User vermehren sich wie die Hasen - statt 3-4 nach einem Monat 12!
-und alle wollen quasi gleichzeitig auf die gleichen zwei Tabellen
mit Stammdaten zugreifen *brrrr*
-ach ja last but not least, so nach einem Jahr, wenn alle Deine DB mit Deinen Daten so richtig lieben, ja täglich danach gieren, musst Du erkennen das das Ding reoganisieren solltest. Und auf Grund des inzwischen massiven Datenvolumens (Historisierung) heisst, dass dass die Tabellen „geschlossen“ bleiben -yupiehhh :wink:

Okay, alles böse böse übertrieben und Du wirst ja auf Grund des erfolgreichen Projektes nach oben beförderst und bist nicht mehr dafür verantwortlich… gelle? *pfeifzwischter*

viele Grüsse
Peter

OK
Hallo José, Hallo Giuseppe,

sorry, ich habe den Bezug zu client-server als nicht so wichtig erachtet, weil meine Lösung einfacher ist und das gleiche bewirkt.

Access ist eine Desktop-Datenbank. Wenn Du unbedingt eine
Client/Server-Anwendung programmieren möchtest,
mußt Du auf
eine „richtige“ Datenbank zurückgreifen, z.B. MS-SQL Server,
Oracle oder MySQL.

Ich gebe zu, daß ich soetwas noch nie programmiert habe, aber wenn es wirklich nicht funktionieren sollte, kann ich die Access-DB sehr einfach in ein MS-SQL-Format konvertieren. Aber mittels OBDC-Zugriff müßte es schnurz und piepegal sein, welche Datenbank dahinter hängt, wenn die sonstigen Parameter stimmen, denke ich.

(Ich hoffe, Dir muß ich den Unterschied zwischen Desktop- und
Serverdatenbanken nicht erklären).

Das mußt Du nicht, denn mein Denkansatz ist ein anderer und da würde ich Access nehmen und ich meine, daß das funktionieren kann.

_Habe kaum Erfahrung in Office-Programmierung, deshalb stelle ich mir das bisher so vor, daß auf einem Rechner Access mit einer geöffneten Datenbank läuft und mehrere andere Rechner über ein internes Netzwerk ihre Anfragen an dieses Access schicken. Der muß dann die entsprechenden Schreib-, Leserechte vergeben bzw. den Zugriff gegebenen falls verweigern.

Ist der Ansatz vom Prinzip her richtig, oder gibt es da eine simplere Lösung? _

Das muß ich, denke ich, nicht mehr näher erläutern.