Mir scheint, Du hast irgendwas gewaltig missverstanden. Der Normalfall, wie man mit Access arbeitet ist, dass die Datei auf einer Platte liegt (Festplatte, ZIP, Netzlaufwerk, andere M�glichkeiten). Dann holt sich Access "seine" Datei und macht alle Aktionen die damit erforderlich sind.
Ist da nun irgendas mit http:// oder ftp:// im Spiel haben wir keine Festplatte mehr, sondern ein v�llig anderes �bertragungsmedium. Und keine Platte mehr in irgendeiner Form. Der Normalfall d�rfte eher der sein, dass man Daten auf einem Webserver mit Formularen pflegt. Damit z.B. vermeidet dass jedesmal die komplette Datei/Tabelle �bertragen wird, was im Plattenscenario der Fall ist. Da Du nun Intranet hast und weisst, dass die Datei ja so oder so auf einem Server liegt, den Du auch direkt anfahren kannst, k�nntest Du eine Netzwerkverbindung zu der Platte und letztlich der MDB Datei herstellen. Ein Problem das dabei sofort auftritt: wenn Du interaktiv einen Satz �nderst ist der Satz f�r den Webserver-Benutzer gesperrt. Also in Kurzform, es ginge wohl mehr schlecht als recht, aber es ginge. Sauberer Stil ist es nicht. Entweder gleich eine vern�nftige Unternehmensdatenbank (SQL Server, MSDE) auf der dann auch verschiedene Leute mit verschiedenen Clients drauf arbeiten k�nnen. Oder die Accessdatenbank auf dem Server wird nur vom Server bearbeitet. Und wenn Du selbst Daten �ndern willst, dann �ber Formulare die Du noch baust. Oder vielleicht noch ganz magerer Ansatz: die bearbeitest die Datei lokal bei Dir und kopierst die ge�nderte Datei von Zeit zu Zeit neu auf den Server. Dann darf aber von den Intranet Nutzern niemand was reinschreiben, sonst verhaut es Dir wieder die ganze Geschichte. -- Viele Gr��e Hubert Daubmeier | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
