🚀 go-pugleaf

Moin!

On 10 Jan 1999 16:59:14 GMT
	"Pascal Eugster" <eugster4@centralnet.ch> wrote:
[schnipp]
> und Acces ist das glaube ich nicht so einfach realisierbar. Also gibt es da
> einige Tips fuer SQL oder sollte ich eine ganz andere Datenbank als Backend
> verwenden (Als Front-End sollte Access bleiben, da ich keine Lust habe die
> ganze Oberfl�che mit all den Spielerein fuer unsere Mitarbeiter neu machen
> zu muessen). Fuer einige Tips w�re ich dankbar

Wie ich den Mailinglisten von PostgreSQL entnehmen konnte, geht das
mit PG ab Version 6.4 (aktuell 6.4.2) anscheinend ganz gut. Die
Datenbank l�uft unter Linux, die Clients greifen via Access und ODBC
auf das RDBMS zu. Es kommen fast w�chentlich verbesserte ODBC-Treiber
raus.

Solltest dich mal bei http://www.postgres.org/ umsehen. Die
archivieren die ML, glaub ich.

MfT
  Guido
-- 
We can defeat gravity.  The problem is the paperwork involved.

On 10 Jan 1999 16:59:14 GMT, "Pascal Eugster" <eugster4@centralnet.ch> wrote:

>Also wir haben eine Access-Datenbank die auf einem SAMBA-Server vor sich
>hin vegetiert. Das Problem ist, dass das langsam aber sicher zu langsam
>wird, da bei jeder Anfrage der ganze Mist �ber Netz geschickt werden muss.
>Nun suche ich einen Datenbank Back End der die Daten verwaltet und Abfragen
>lokal auf dem Linux-server berechnen und nur die Resultate zur�ck liefert.
>Ich weiss das geht mit SQL und ODBC-Treibern ganz gut. Ich hab das auch
>schon ausprobiert. Das Problem ist jetzt, dass ich jedoch nich nur Abfragen
>machen m�chte, sondern auch Werte in den Tabellen ver�nder m�chte (Auf das
>Ver�ndern von Abfrageresultaten kann ich vermutlich verzichten). Nur SQL
>und Acces ist das glaube ich nicht so einfach realisierbar. Also gibt es da
>einige Tips fuer SQL oder sollte ich eine ganz andere Datenbank als Backend
>verwenden (Als Front-End sollte Access bleiben, da ich keine Lust habe die
>ganze Oberfl�che mit all den Spielerein fuer unsere Mitarbeiter neu machen
>zu muessen). Fuer einige Tips w�re ich dankbar

mysql und der passende ODBC-Treiber sollten alles sein, was Du brauchst.
Anstelle die Tabellen selbst im .mdb-File zu halten, kannst Du auch einfach
Links auf die entsprechenden ODBC-DSNs legen und als ODBC-Treiber den
mysql-Treiber nehmen. Dann bleiben im .mdb-File nur noch Abfragen, Formulare,
Module etc.

 Frank-Christian Kr�gel

-- 
----------------------------------------------------------------------
fchk@i-online.ohz.north.de - 2:2426/3060      http://www.ohz.north.de/

Pascal Eugster wrote:
> 
> Also wir haben eine Access-Datenbank die auf einem SAMBA-Server vor sich
> hin vegetiert. Das Problem ist, dass das langsam aber sicher zu langsam
> wird, da bei jeder Anfrage der ganze Mist �ber Netz geschickt werden muss.
> Nun suche ich einen Datenbank Back End der die Daten verwaltet und Abfragen
> lokal auf dem Linux-server berechnen und nur die Resultate zur�ck liefert.
> Ich weiss das geht mit SQL und ODBC-Treibern ganz gut. Ich hab das auch
> schon ausprobiert. Das Problem ist jetzt, dass ich jedoch nich nur Abfragen
> machen m�chte, sondern auch Werte in den Tabellen ver�nder m�chte (Auf das
> Ver�ndern von Abfrageresultaten kann ich vermutlich verzichten). Nur SQL
> und Acces ist das glaube ich nicht so einfach realisierbar. Also gibt es da
> einige Tips fuer SQL oder sollte ich eine ganz andere Datenbank als Backend
> verwenden (Als Front-End sollte Access bleiben, da ich keine Lust habe die
> ganze Oberfl�che mit all den Spielerein fuer unsere Mitarbeiter neu machen
> zu muessen). Fuer einige Tips w�re ich dankbar
> 
> Tschuess
> 
> Pascal
Hallo Pascal,

nimm Adabas D fuer Linux. Da kannst Du Access als Frontend behalten. 
Laeuft bei mir seit ca. 1,5 Jahren sehr stabil.

Gruss
 Torsten
-- 
--------------------------------------
Dipl.-Ing. Torsten Hoppe
hoppe@cns.mpg.de

day care clinic of cognitive neurology
D-04103 Leipzig
Liebigstrasse 22a
http://www.uni-leipzig.de/~tk/

phon +49 341 9724976
fax  +49 341 9724989
--------------------------------------

Torsten Hoppe wrote:
> 
> Pascal Eugster wrote:
> >
> > Also wir haben eine Access-Datenbank die auf einem SAMBA-Server vor sich
> > hin vegetiert. Das Problem ist, dass das langsam aber sicher zu langsam
> > wird, da bei jeder Anfrage der ganze Mist �ber Netz geschickt werden muss.
> > Nun suche ich einen Datenbank Back End der die Daten verwaltet und Abfragen
> > lokal auf dem Linux-server berechnen und nur die Resultate zur�ck liefert.
> > Ich weiss das geht mit SQL und ODBC-Treibern ganz gut. Ich hab das auch
> > schon ausprobiert. Das Problem ist jetzt, dass ich jedoch nich nur Abfragen
> > machen m�chte, sondern auch Werte in den Tabellen ver�nder m�chte (Auf das
> > Ver�ndern von Abfrageresultaten kann ich vermutlich verzichten). Nur SQL
> > und Acces ist das glaube ich nicht so einfach realisierbar. Also gibt es da
> > einige Tips fuer SQL oder sollte ich eine ganz andere Datenbank als Backend
> > verwenden (Als Front-End sollte Access bleiben, da ich keine Lust habe die
> > ganze Oberfl�che mit all den Spielerein fuer unsere Mitarbeiter neu machen
> > zu muessen). Fuer einige Tips w�re ich dankbar
> >
> > Tschuess
> >
> > Pascal
> Hallo Pascal,
> 
> nimm Adabas D fuer Linux. Da kannst Du Access als Frontend behalten.
> Laeuft bei mir seit ca. 1,5 Jahren sehr stabil.
> 

Wie funktioniert die anbindung an Access so vom Prinzip her?

Frank-Christian Kruegel wrote:
> 
> On 10 Jan 1999 16:59:14 GMT, "Pascal Eugster" <eugster4@centralnet.ch> wrote:
> 
> >Also wir haben eine Access-Datenbank die auf einem SAMBA-Server vor sich
> >hin vegetiert. Das Problem ist, dass das langsam aber sicher zu langsam
> >wird, da bei jeder Anfrage der ganze Mist �ber Netz geschickt werden muss.
> >Nun suche ich einen Datenbank Back End der die Daten verwaltet und Abfragen
> >lokal auf dem Linux-server berechnen und nur die Resultate zur�ck liefert.
> >Ich weiss das geht mit SQL und ODBC-Treibern ganz gut. Ich hab das auch
> >schon ausprobiert. Das Problem ist jetzt, dass ich jedoch nich nur Abfragen
> >machen m�chte, sondern auch Werte in den Tabellen ver�nder m�chte (Auf das
> >Ver�ndern von Abfrageresultaten kann ich vermutlich verzichten). Nur SQL
> >und Acces ist das glaube ich nicht so einfach realisierbar. Also gibt es da
> >einige Tips fuer SQL oder sollte ich eine ganz andere Datenbank als Backend
> >verwenden (Als Front-End sollte Access bleiben, da ich keine Lust habe die
> >ganze Oberfl�che mit all den Spielerein fuer unsere Mitarbeiter neu machen
> >zu muessen). Fuer einige Tips w�re ich dankbar
> 
> mysql und der passende ODBC-Treiber sollten alles sein, was Du brauchst.
> Anstelle die Tabellen selbst im .mdb-File zu halten, kannst Du auch einfach
> Links auf die entsprechenden ODBC-DSNs legen und als ODBC-Treiber den
> mysql-Treiber nehmen. Dann bleiben im .mdb-File nur noch Abfragen, Formulare,
> Module etc.
> 

Geht dann nicht der Geschwindigkeitsvorteil verlohren, denn die abfragen
werden dann auf dem client durchgefuehrt und dazu muss die ganze Tabelle
ueber netz gesogen werden, oder Taeusche ich mich da etwa? Bis jetzt
habe ich die Datenbank in einen Front-end und back-end aufgeteilt.
beides auf Access. front-end ist lokal auf jedem client auf der HD und
Backend auf dem SAMBA-server, eben nur, dass das einfach mit der Zeit zu
langsam wird. 

Eine Idee waere doch, wenn man, wie du geraten hast, die Tabellen mit
Links einbinden und fuer die abfragen pass-trough-abfragen nimmt. Dann
wird die abfrage auf dem sql-server ausgefuehrt und das resultat in eine
tabelle zurueckgeliefert. Mit einer Pass-through-abfrage habe ich schon
etwas rumgespielt (1/2h) und festgestellt, dass die Resultat, die durch
eine solche Abfrage geliefert werden nicht veraendert werden koennen.
ist das generel so? (ist eigentlich nicht so schlimm wenn das veraendern
der abfrage ergebnisse nicht funktioniert)

Hallo

Pascal Eugster wrote:
- snip -
> Wie funktioniert die anbindung an Access so vom Prinzip her?

Ich habe das 'mal mit einer orcale-DB gemacht.

ODBC-Datasource einrichten:
Start -> Settings -> Control panel -> ODBC...
-> System DSN -> Add... (nicht User DSN, sonst Benutzerabh�ngig)
Typ SQL-Server w�hlen (m�glicherweise ist das nur f�r MS-SQL
server. Dann musst du einen ODBC-treiber zur jeweiligen DB
software noch installieren z.B. MySQL-ODBC oder so �hnlich.
Dann server und einen namen und was er sonst noch will angeben...

In Access:
file -> external data -> link tables...
dann 'ODBC Datasource' oder so �hnlich bei 'filetypes' w�hlen..
Dann kannst du eine DataSource ausw�hlen...
Danach w�hlst du die tabellen, die du gerne linken m�chtest...

gruss
 Stefan

-- 
"Those are my principles! And if you don't
like them... well, I have others..."
	-- Groucho Marx

Pascal Eugster schrieb:
> 
> Frank-Christian Kruegel wrote:
> >
> > On 10 Jan 1999 16:59:14 GMT, "Pascal Eugster" <eugster4@centralnet.ch> wrote:
> >
> > >[Access-DB auf Samba-Server beschleunigen]
> >
> > [mysql und der passende ODBC-Treiber]
> 
> [Geschwindigkeit, Ausfuehrung von Queries auf Client oder Server]

Im Prinzip werden bei einer _echten_ Client/Server-Anwendung die
Abfragen auf dem Server ausgefuehrt; das ist auch der Fall, wenn Access
auf eine SQL-Server-DB (egal welchen Herstellers) zugreift. 

Allerdings muss man bei der Konstruktion der Queries hoellisch
aufpassen, dass die Queries auch tatsaechlich auf dem Server ausgefuehrt
werden koennen (sonst werden naemlich alle benoetigten Tabellen lokal
heruntergeladen, das Query ausgefuehrt, das Zwischenresultat an den
Server zurueckgeschickt und von diesem wiederum an den Client
zurueckgegeben).

Um sicherzugehen, dass die Queries auf dem Server ausgefuehrt werden,
kannst du Pass-Through-Abfragen verwenden. Wenn in diesen etwas
vorkommt, das nicht auf dem Server ausgefuehrt werden kann, bekommst du
naemlich eine "schoene" Fehlermeldung. Generell musst du aufpassen, dass
in Queries nicht auf ein Feld auf einem Formular oder auf eine
Access-Funktion bezug genommen wird. Folgende Abfragen koennen von
keinem Server ausgefuehrt werden:

select * from Adressen where Nachname Like
[Formulare]![SuchFormular]![MeinSuchFeld]

oder

select * from Adressen where Nachname Like UCase$("Meier")

Das bedeutet, dass du Queries mit Parametern in aller Regel in einem
Stueckchen Access Basic zusammenschusterst und dann auf den Server
loslaesst.


> [Resultset Readonly von einer Pass-Through-Abfrage]

Es ist von der Perfomance her generell schlecht, ein Resultset einer
SQL-Server-Abfrage schrittweise durchzulaufen und Werte zu veraendern.
Updates, Inserts und Deletes fuehrt man besser direkt mit einem
SQL-Statement aus; aergerlicherweise bedeutet das, dass man einen
ansehnlichen Teil der Programmlogik umschreiben muss (kenne ich aus
eigener Erfahrung) ;( 

Ebenfalls zu beachten ist, dass man sich mit Pass-Through-Abfragen (und
evtl. Stored Procedures auf dem Server selbst) in eine Abhaengigkeit von
einer bestimmten Server-Software begibt. 

Es ist also nix mit dem "einfach 'mal schnell die ODBC-Quelle aendern".
Ich wuerde dir die Lektuere der MSDN-CD's oder der M$-Knowledgebase
empfehlen, dort gibt es einige Artikel ueber den Umgang mit
Access-Frontend und SQL-Server-Backend (natuerlich spezifisch fuer
MS-SQL-Server, aber auch fuer andere Server anwendbar).

Nach all' diesen Einschraenkungen fragt es sich, ob Access wirklich noch
das ideale Tool fuer das Datenbank-Frontend ist. _Meistens_ komme ich
zum Schluss, dass es trotzdem ein gutes Werkzeug ist, da z.B. Reports
und verschiedene Datenbank-Controls (z.B. Lookup-Comboboxen) sehr sauber
integriert sind und die Anwendungsentwicklung im Vergleich zu einer
anderen Umgebung (wie C[++]) relativ "billig" ist - allerdings nicht
fuer grosse Projekte! Meine Faustregel: Anwendungen, die mehr als ca.
einen Mannmonat benoetigen, sollten besser _nicht_ in Access geschrieben
werden.

Ups, das passt jetzt schon beinahe nicht mehr nach *linux*.
<tschuldigung>

Gruss,
Matthias

-- 
___________________________________________________________
leisi@codelab.ch          2.5:1.5            Matthias Leisi