ODBC und ODBC DSN ist ein Unterschied. Der zuerst genutzte Connection String war ein ODBC Connection String. Aber daf�r muss kein Provider eine DSN eirichten und in Rechnung stellen.
> Ich nehme mal an, das ADO(X) sich drum k�mmert, das der Pool nicht > andere Aktionen unterbindet... > Die Annahme reicht mir nicht, genaugenommen glaube ich es auch nciht. Ich werde es mal auf meinem Heimserver testen. Um ein letztes mal auf den Ursprung der Diskussion zu kommen. Ich habe schon erlebt dass die AccessDB bei 3 parallelen Nutzern neue Connections verweigert hat (War die unperformante Session Variante, deswegen weiss ich dass so genau). Bei 3 Benutzern ist prinzipiell noch kein Performenceengpass da... F�r die, die MS Connection Pooling nicht, aber eine MSDE nutzen k�nnen, w�re es vielleicht auch interessant, wegen der eingenauten 5 User h�rde. Aber wie gesagt, das sollen nur Optionen f�r Spezialf�lle sein. Ich biete es an, kl�re aber auch �ber etwaige Nachteile und andere L�sungen (Die jetzt noch um die Access MS Connection Pooling-Geschichte erweitert wird) Voreinstellung ist und bleibt die Version, die Connection pro Seite zu schliessen, was ja auch die Basis f�r MS Connection Pooling darstellt. Gruss, Andreas Roth -------------------------------------- [EMAIL PROTECTED] *jetzt mit Chat* http://www.EuphoriasChild.DarkTech.org -------------------------------------- > -----Urspr�ngliche Nachricht----- > Von: Claudius Ceteras [mailto:[EMAIL PROTECTED]] > Gesendet: Freitag, 4. Januar 2002 13:30 > An: ASP Datenbankprogrammierung > Betreff: [aspdedatabase] RE: AW: RE: AW: RE: AW: RE: AW: RE: > AW: RE: Nur > eine Access C onnectio n? > > > > > > > > Die angesprochenen Performanceverbesserungen sind mir > > > > wohlbekannt. Aber > > > > > > Welche Verbesserungen? Ich sprach von Verschlechterungen. > > > > > > > Du hast einige Verbesserungsm�glichkeiten angesprochen wie > > zwischenspeichern > > von Werten in Applikation Variablen oder Textfiles. > > Aja... Aber ich sehe kein Problem, wieso z.B. Userdaten o.�. nicht im > Speicher gehalten werden k�nnen und bei neuen eintr�gen geupdatet > werden... > > > > > > Jeder Provider, der seinen Job ernst nimmt wird wenn M�glich > > > connection-Pooling einstellen, denn es bringt auch ihm Vorteile... > > > Weniger starke Auslastung der Server bedeutet, dass er mehr > > Sites pro > > > Server hosten kann... > > > > > > > F�r SQL Server stimme ich dir generell mal zu, aber vorsicht > > bei Access. > > Wenn du das Connection Pooling f�r Access aktivierst hast du > > ein Problem, > > das wir bislang noch garnicht angesprochen haben, es wird je > > nachdem extrem > > Schwierig die Connections zu Wartungszwecken zu trennen (zB. DB > > Komprimierung). �ber solche Anspr�che kann sich ein Provider > > doch nicht > > einfach hinwegsetzen. > > Das Problem hat man so oder so... W�hrend einer Komprimierung oder > kopieren(download per ftp o.�.) muss man den Zugriff auf die DB > verhindern... > > > > > �brigens gelten Deine Argumente auch gegen Dich... > > > Du nutzt ODBC, aber bei den meisten Providern kostet das > > > Einrichten von > > > ODBC DSNs Geld... > > > > Es wird doch eine DSN lose Connection Benutzt? > Dann habe ich Dich vielleicht verwechselt... Ich dachte Du willst > unbeding ODBC nutzen.. > > > > > > Ja, aber was ist den �berhaupt der Vorteil, den mann sich mit > > > Performance-Verlust durch Dein System erkauft? > > > > > > > Einfache Konfiguration, Downloads von meiner Seite laufen in einer > > gemeinsamen Umgebung was eine Interaktion erlaubt, ohne zu > > bedingen, das > > alles installiert ist. Einfacheres verst�ndniss der Vorg�nge > > im Quellcode, > > weil nicht alles mit Standartvorg�ngen zugekleistert ist. > Cookiefreies > > Sessionhandling, hohe felxibilit�t bei einfacher installation. > > Das h�rt sich ja gar nicht so schlecht an... Aber das eigene Pooling > sehe ich trotzdem nicht ein... Du handelst Dir wahrscheinlich mehr > Probleme ein, als das Du l�st... > F�r geringes Anfragenaufkommen ist Pooling nicht n�tig, weil > es auch so > schnell genug ist... > Bei h�herem Anfragenaufkommen, wenn Pooling eigentlich interessant > w�rde, bremst das Threading jeden Performance-Gewinn aus und > verlangsamt > noch zus�tzlich... > > Also: eigenes Pooling ist auf jeden Fall kontraproduktiv und > ist ja auch > nicht n�tig, nur um DB-Anfragen zu vereinfachen... > > > Ich f�rchte, du hast eine wichtigen Punkt missverstanden: Ich > > will hier > > keine Umgebung schaffen die nachher jeder nutzen soll, weil > > das dann meinem > > Ego gefallen w�rde. V�lliger Schmarrn. Aber Ich hab diesen > > N�, so hab ichs nicht verstanden... Wollte bloss die Nachteile dieses > Vorgehens aufzeigen > > > Chat geschrieben > > und ich habe noch ein Glossar zum Download auf der Page. > Beiden fehlt > > beispielsweise eine Benutzerverwaltung. Als n�chstes bastle > > ich an einem > > Forum, da der Chat sicher viele Fragen aufwerfen wird. Das > > werde ich dann > > nat�rlich auch im Quellcode ver�ffnetlichen. Auch hier ist > wieder eine > > Verwaltung gefragt. > > Also war meine �berlegung, erst einmal eine Basis zu > > schaffen, die all diese > > Applikationen gemeinsam nutzen k�nnen und die so leicht wie m�glich > > konfigurierbar und nutzbar ist, auch f�r jene, die nicht wissen. > > > > Gru�, Andreas. > > PS: Wir haben hier 2 St�hle, eine Meinung. Wir stehen hier nicht > > Grunds�tzlich gegeneinander > > Sowieso nicht... > > > Claudius > > > | [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 > | [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
