Problem mit Datenbankzugriff

Hallo.

Sporadisch kommt folgende Fehlermeldung, siehe Anhang.

Bitte um Rat…

Habe in der Webconfig den Session-Timeout hoch genug eingetragen.

Wie gesagt, er kommt ab und an plötzlich. Danach ist ein Anmeldung an der DB nicht mehr möglich. Ein Neustart des kompletten Servers hilft meistens weiter.

Ideen??

Was steht im Log der DB?

Andreas

Keine, solange du bloß einen Screenshot ohne Aussagekraft lieferst.

Dort steht zwar was von einem ODBC Error aber welcher Fehler genau, welche Fehlermeldung ect, das fehlt alles.

Kann es evtl. sein, dass Du alle Verbindungen belegst? Sprich, Du öffnest bei jeder Anfrage eine neue Verbindung zur Datenbank, schließt diese aber nicht und nach einer gewissen zeit sind die nun mal alle belegt?

Hmm, es wäre hilfreich wenn Du angeben könntest welchen ADO.NET
OleDBProvider Treiber Du zu Connectionanbindung verwendest.
Die Klasse im Namespace aus der die Exception resultiert deutet
darauf hin, das Du eine Windows ODBC Datenquelle definiert hast
und darauf irgendwie per Postgres Bridge to ODBC drauf zugreifst.
Wenn ja, dann verwende lieber mal den nativen offiziellen Postgres
.NET Treiber, sollte nicht zu schwierig sein den auszutauschen.

Danke für eure Hilfe.

Also hier mal einen Auszug, zur DB-Verbindung (Programmiersprache: VB).

'Variablen für Datenbankverbindung deklarieren
        Dim connStr As String
        Dim command As New OdbcCommand
        connStr = Session("conString")

        Dim conn As New OdbcConnection(connStr)
        command.Connection = conn
        'Wenn erfolgreich, dann
        Try
            'Verbindung zur Datenbank öffnen
            conn.Open()
            ......
            ..... tu was...
            conn.Close()
        Catch ex As Exception

        End Try

Also die Verbindungen schließe ich jedesmal wieder.

Wie komme ich an den Log der DB?



Hier jetzt einen Ausschnitt aus der WebConfig:

<?xml version="1.0"?>
<configuration>
    <configSections>
        <sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
            <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
                <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
                <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
                    <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="Everywhere"/>
                    <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
                    <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
                    <section name="roleService" type="System.Web.Configuration.ScriptingRoleServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/></sectionGroup>
            </sectionGroup>
        </sectionGroup>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
            <section name="Ore_Database.My.MySettings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>
        </sectionGroup>
    </configSections>
    <appSettings>
    <add key="ConString" value="Driver={PostgreSQL Unicode};Server=xx.xx.xx.xx;Port=5432;DSN=Bla;Database=Bla;"/>
    </appSettings>
    <connectionStrings>
    <add name="ConnectionString" connectionString="DSN=Bla;DATABASE=Bla;SERVER=xx.xx.xx.xx;PORT=5432;UID=xxxxx;pwd=xxxxx;Encoding=UNICODE;ReadOnly=0;Protocol=6.4;FakeOidIndex=0;ShowOidColumn=0;RowVersioning=0;ShowSystemTables=0;ConnSettings=;Fetch=100;Socket=8192;UnknownSizes=0;MaxVarcharSize=254;MaxLongVarcharSize=8190;Debug=0;CommLog=0;Optimizer=1;Ksqo=1;UseDeclareFetch=0;TextAsLongVarchar=1;UnknownsAsLongVarchar=0;BoolsAsChar=1;Parse=0;CancelAsFreeStmt=0;ExtraSysTablePrefixes=dd_;LFConversion=1;UpdatableCursors=0;DisallowPremature=0;TrueIsMinus1=0;BI=0;ByteaAsLongVarBinary=0;UseServerSidePrepare=0" providerName="System.Data.Odbc"/>

Hilft dir das weiter marc9022?
Wie kann ich aus der Windows ODBC Datenquelle einen nativen offiziellen Postgres .NET Treiber erstellen?

Wie kann ich aus der Windows ODBC Datenquelle einen nativen offiziellen Postgres .NET Treiber erstellen?

Du musst gar nix erstellen. Einfach den .Net Treiber bei PgFoundry runterladen, DLL einbinden und verwenden. Geht dann genau wie ODBC, nur halt statt ODBCCommand einfach NpgsqlCommand und so weiter.

Npgsql: PgFoundry: Npgsql .Net Data Provider for Postgresql: Project Info
Doku: Npgsql: User’s Manual

Danke für die flotte Info/Hilfe.

Hmm, auf PgFoundry: Welcome werde ich nicht ganz schlau, welchen Treiber ich downloaden muss. Da steht auch etwas von C#, ich nutze Visual Basic.

Möchte aber nicht riskieren, dass die komplette Anwendung nach der Installation nicht mehr funktioniert.
Die Anwendung ist sehr komplex. Müsste dann bei jedem DB Zugriff der ConnectionString angepasst werden?

Worin liegt überhaupt der Unterschied/Vorteil?

Sollte gut überlegt sein, bevor man so ein Update einspielt und hinterher gar nichts mehr funktioniert.

Den Treiber kannst Du meines wissens nach auch mit VB verwenden. In .Net ist es egal, ob die Assemblys mit C# oder VB programmiert wurden, da diese in den selben Zwischencode angepasst werden. Die Verbindungszeichenfolge muss natürlich angepasst werden, halt einmal in der Web.Config, etc, Diese hat man ja normalerweise global hinterlegt.

Stimmt. Auf jeden Fall rächt es sich hier bitter böse wenn
ein Fehler in der Schnittstellenbibliothek vorliegt und der
Source dann closed ist und man keine Chance hat irgendwas
daran zu ändern! Dann ist meist guter Rat teuer, es kommt
zu üblen Workarrounds.

Ich dachte mal bei .NET würde das jetzt zumindest von Seiten
Microsoft in Richtung eigener Standardtreue zumindest etwas besser
werden, aber da ist man schnell desilusioniert wenn man mal bedenkt
das alle nicht MS Treiber via oleProvider xyz und z.B MSSQL via
xyzu.mssql angesprochen werden. Die werden halt nie schlau,
nur der Kunde am Ende hat dann die Probleme.

Hallo AndreasBeginner,

Wie ich schon mal bei einem anderen Thread erwähnt habe (http://www.pg-forum.de/sql/3301-datum-tabelle-einf-gen.html#post17294), solltest du den nativen ADO.NET Provider benutzen. Dieser ist von dieser Seite zu beziehen (Npgsql - .Net Data Provider for Postgresql).

Desweiteren wäre eine detaillierte Fehlermeldung hilfreicher. Dies kannst du auch mittels Debugger feststellen und auch sehen wann und wo der Fehler entsteht.

Aus meiner Sicht ist die Fehlermeldung nichts sagend und du hast auch nicht erwähnt was du da im Moment machst und wann und wo der Fehler auftritt.

Bitte verwende bei Connection immer das using Statement, damit die offene Verbindung automatisch geschlossen wird und zurück an ConnectionPool geht.

@marc9022: Wenn die ADO.NET Provider richtig programmiert sind, dann kann man den Namespace System.Data.Common mit den Schnittstellen arbeiten. Dadurch kannst du beliebig andere ADO.NET Provider / Datenbanken benutzen. Das größere übel ist eher das man die SQL Statements ggf. ändern muss, da diese nicht von jeder Datenbank SQL konform umgesetzt ist. Bestes Beispiel LIMIT (MySql) und TOP.