ADO.NET: DB-Zugriff verursacht nur auf bestimmten PCs eine Ausnahme

verwendetes Datenbanksystem: SQLBase 11.7 unnd 12.0

Hallo!

Ich habe ein Programm, welches u. a. den Versand von E-Mails in einer SQL-Datenbank protokolliert. Dieses Programm ist sowohl bei uns intern als auch bei einigen Kunden extern in Verwendung. Bis auf einen Kunden, funktioniert das Programm fehlerfrei.

Bei einem Kunden mit einem kleinen Netzwerk (Server: Windows 2012R2, Arbeitsstationen: Windows 8.1 – alles 64 Bit und immer aktuell) funktioniert das Programm auf dem Server und auf einer Arbeitsstation bis vor wenigen Tagen fehlerfrei. Auf allen anderen Rechnern funktioniert der Datenbankzugriff nicht.

Fehlerbeschreibung:

Das Programm verwendet eine Schemadatei mit der Beschreibung der verwendeten Datenbanktabelle. Ist diese Datei nicht vorhanden, so wird sie einmalig erstellt:

		private void GetSchema(string table, SQLBaseConnection con, bool schemaonly)
		{
			using (SQLBaseDataAdapter da = new SQLBaseDataAdapter($"SELECT * from {table}", con))
			{
				using (DataTable dt = new DataTable())
				{
					if (!File.Exists(FileSchema))
					{
						da.FillSchema(dt, SchemaType.Mapped);
						dt.WriteXmlSchema(FileSchema);

						if (!schemaonly)
						{
							FillDts(table, dt);
						}
					}
					else
					{
						dt.ReadXmlSchema(FileSchema);
						FillDts(table, dt);
					}
				}
			}
		}

D. h. wenn die Schemadatei nicht existiert, so werden die Infos mit

da.FillSchema(dt, SchemaType.Mapped);

eingeholt und die Datei danach geschrieben. In diesem Fall stellt dieser Befehl den ersten Datenbankzugriff dar.

Existiert die Schemadatei, so wird an einer anderen Programmstelle folgender Code ausgeführt:

		private int Count()
		{
			int RecordCount = 0;

			try
			{
				using (SQLBaseCommand cmd = new SQLBaseCommand($"select count(*) from {db_DBKOMMPROTOKOLL} where id = {CommID}", con))
				{
					con.Open();

					// Es muss mindestens ein Eintrag vorhanden sein, da er von ISEntial erstellt wird.
					if ((RecordCount = Convert.ToInt32(cmd.ExecuteScalar())) <= 0)
					{
						throw new Exception("Es wurde kein passender Datensatz in der Protokolldatei gefunden.");
					}
					con.Close();
				}
			}
			finally
			{
				con?.Close();
			}
			return RecordCount;
		}

In diesem Fall stellt die Anweisung

con.Open();

den ersten Datenbankzugriff dar.

Wie beschrieben, das funktioniert fehlerfrei bis auf einige PCs eines Kunden. Im ersten Fall, wenn die Methode FillSchema als erster DB-Zugriff aufgerufen wird, quittiert diese ihren Dienst mit folgender Ausnahme:

Fehlermeldung:
Informationen über das Aufrufen von JIT-Debuggen
anstelle dieses Dialogfelds finden Sie am Ende dieser Meldung.

************** Ausnahmetext **************
System.AggregateException: Mindestens ein Fehler ist aufgetreten. ---> System.ComponentModel.Win32Exception: Das System kann die angegebene Datei nicht finden
bei System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
bei System.Diagnostics.Process.Start()
bei System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
bei Gupta.SQLBase.Data.DatabaseProcess.StartDatabase(String ini)
bei Gupta.SQLBase.Data.DatabaseProcess.AutoStart()
bei Gupta.SQLBase.Data.SQLBaseConnection.AutoStartServerIfNeeded()
bei Gupta.SQLBase.Data.SQLBaseConnection.Connect(Boolean isServerConnection)
bei Gupta.SQLBase.Data.SQLBaseConnection.CreateNewConnection(ConnectionPool pool)
bei Gupta.SQLBase.Data.SQLBaseConnection.CreateConnection()
bei Gupta.SQLBase.Data.SQLBaseConnection.Open()
bei System.Data.Common.DbDataAdapter.FillSchemaInternal(DataSet dataset, DataTable datatable, SchemaType schemaType, IDbCommand command, String srcTable, CommandBehavior behavior)
bei System.Data.Common.DbDataAdapter.FillSchema(DataTable dataTable, SchemaType schemaType, IDbCommand command, CommandBehavior behavior)
bei System.Data.Common.DbDataAdapter.FillSchema(DataTable dataTable, SchemaType schemaType)
bei ise.DBKOMMPROTOKOLL.GetSchema(String table, SQLBaseConnection con, Boolean schemaonly)
bei ise.DBKOMMPROTOKOLL..ctor(EMail _em, Boolean schemaonly)
bei ise.EMail.<TestSetParam>b__10_0()
bei System.Threading.Tasks.Task.InnerInvoke()
bei System.Threading.Tasks.Task.Execute()
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
bei System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
bei ise.EMail.dbLogEMail(String status, String error, Boolean Silent)
bei ise.EMail.SendMail_SMTP(Boolean Silent, Form frmParent)
bei ise.EMail.Send(Boolean Silent, Form frmParent)
bei ise.frmPDFViewer.ToolStripMenuItemEmailSenden_Click(Object sender, EventArgs e)
bei System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
bei System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
bei System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
bei System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
bei System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
bei System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
bei System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
bei System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.ScrollableControl.WndProc(Message& m)
bei System.Windows.Forms.ToolStrip.WndProc(Message& m)
bei System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
---> (Interne Ausnahme #0) System.ComponentModel.Win32Exception (0x80004005): Das System kann die angegebene Datei nicht finden
bei System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
bei System.Diagnostics.Process.Start()
bei System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
bei Gupta.SQLBase.Data.DatabaseProcess.StartDatabase(String ini)
bei Gupta.SQLBase.Data.DatabaseProcess.AutoStart()
bei Gupta.SQLBase.Data.SQLBaseConnection.AutoStartServerIfNeeded()
bei Gupta.SQLBase.Data.SQLBaseConnection.Connect(Boolean isServerConnection)
bei Gupta.SQLBase.Data.SQLBaseConnection.CreateNewConnection(ConnectionPool pool)
bei Gupta.SQLBase.Data.SQLBaseConnection.CreateConnection()
bei Gupta.SQLBase.Data.SQLBaseConnection.Open()
bei System.Data.Common.DbDataAdapter.FillSchemaInternal(DataSet dataset, DataTable datatable, SchemaType schemaType, IDbCommand command, String srcTable, CommandBehavior behavior)
bei System.Data.Common.DbDataAdapter.FillSchema(DataTable dataTable, SchemaType schemaType, IDbCommand command, CommandBehavior behavior)
bei System.Data.Common.DbDataAdapter.FillSchema(DataTable dataTable, SchemaType schemaType)
bei ise.DBKOMMPROTOKOLL.GetSchema(String table, SQLBaseConnection con, Boolean schemaonly)
bei ise.DBKOMMPROTOKOLL..ctor(EMail _em, Boolean schemaonly)
bei ise.EMail.<TestSetParam>b__10_0()
bei System.Threading.Tasks.Task.InnerInvoke()
bei System.Threading.Tasks.Task.Execute()<---

************** Geladene Assemblys ************** mscorlib Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34209 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll.

ISEprint Assembly-Version: 3.1.5844.30587. Win32-Version: 3.1.0.0. CodeBase: file:///C:/Program%20Files%20(x86)/ISE/ISEntial/ISEPRINT.EXE.

System.Windows.Forms Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34250 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll.

System.Drawing Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.36337 built by: FX452RTMLDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll.

System Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34239 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll.

System.Printing Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34209 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Printing/v4.0_4.0.0.0__31bf3856ad364e35/System.Printing.dll.

ReachFramework Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34292 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/ReachFramework/v4.0_4.0.0.0__31bf3856ad364e35/ReachFramework.dll.

WindowsBase Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34292 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/WindowsBase/v4.0_4.0.0.0__31bf3856ad364e35/WindowsBase.dll.

mscorlib.resources Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34209 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_de_b77a5c561934e089/mscorlib.resources.dll.

Gupta.SQLBase.Data Assembly-Version: 12.0.0.10579. Win32-Version: 12.0.0.10579. CodeBase: file:///C:/Program%20Files%20(x86)/ISE/ISEntial/Gupta.SQLBase.Data.DLL.

System.Core Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34209 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll.

System.Data Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34209 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll.

System.Configuration Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34209 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll.

System.Xml Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.34281 built by: FX452RTMGDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll.

System.EnterpriseServices Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.33440 built by: FX45W81RTMREL. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll.

System.Windows.Forms.resources Assembly-Version: 4.0.0.0. Win32-Version: 4.0.30319.36213 built by: FX452RTMLDR. CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_de_b77a5c561934e089/System.Windows.Forms.resources.dll.

************** JIT-Debuggen **************
Um das JIT-Debuggen (Just-In-Time) zu aktivieren, muss in der
Konfigurationsdatei der Anwendung oder des Computers
(machine.config) der jitDebugging-Wert im Abschnitt system.windows.forms festgelegt werden.
Die Anwendung muss mit aktiviertem Debuggen kompiliert werden.

Zum Beispiel:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

Wenn das JIT-Debuggen aktiviert ist, werden alle Ausnahmefehler an den JIT-Debugger gesendet, der auf dem
Computer registriert ist, und nicht in diesem Dialogfeld behandelt.

Im Zweiten Fall, wenn die Methode con.Open() – SQLBaseConnection – als erster DB-Zugriff aufgerufen wird, wird folgende Ausnahme geworfen:

Siehe Anhang bzw. Link:

http://ise-software.com/temp/fehler.png

Nun stehe ich auf dem Schlauch, da ich nicht weiß, wer den Fehler verursacht. Ich kann ihn bei mir nicht reproduzieren, so dass ich ziemlich blöd aus der Wäsche gucke.

Da der Fehler nur bei einem einzigen Kunden auftaucht und das nicht auf allen PCs, die alle ziemlich gleich konfiguriert sind, vermute ich, dass der Fehler an deren Einstellungen zu suchen ist. Ich habe mir die Sicherheitsrichtlinien angeschaut – nichts auffälliges gefunden –, Virenscanner und Firewall, sowohl auf den Arbeitsstationen wie auch auf dem Server, ausgeschaltet, die verwendete DLL (Gupta.SQLBase.Data.dll) manuell registriert und die NTFS-Berechtigungen überprüft, alles ohne Erfolg.

Nun frage ich hier und hoffe auf konstruktive Tipps, die mir weiterhelfen.

Im Voraus herzlichen Dank und schöne Pfingsten!

pollito

Also ich weiß nix besonderes, nur was ich hier aus der Fehlermeldung lese:

ich kann mir vorstellen, dass im Connectionstring ein Dateipfad angegeben ist, der nicht gefunden wird.

Oder sonstwo inne SqlBase-Konfiguration muss eine Datei spezifiziert sein, die offsichtlich nicht gefunden wird.

Welche Datei fehlt kannst Du mit ProcMon herausfinden. Ich habe dieses Tool lieben gelernt 😃

Danke für eure Hinweise – die bringen mich auf weitere Gedanken. Es könnte durchaus sein, dass SQLBase hier einen Fehler aufweist. Die Datenbank bzw. deren Client soll neuerdings ohne die berühmte Datei "sql.ini" funktionieren, aber wer SQLBase seit 25 Jahren kennt, weiß ganz genau, wie das zu werten ist.

In der Verbindungszeichenkette ist kein Pfad bzw. keine Datei angegeben, könnte jedoch explizit u. a. genau die Datei "sql.ini" angegeben werden. Auf jeden Fall werde ich mit Process Monitor das Programm überwachen, um zu sehen, was an der Stelle geschieht. Leider jedoch habe ich erst am Dienstag wieder Zugriff auf das Kundennetzwerk

Nochmals herzlichen Dank euch beiden und schöne Pfingsten!

Ich glaube, den Fehler gefunden zu haben. In der Datei "sql.ini", die angeblich vom .NET-Dataprovider nicht mehr benutzt wird, steht folgendes:

[win32client.dll]
comdll=sqlws32
;comdll=sqlapipe
;comdll=sqlwsspx
;comdll=sqlspx32

[win32client.apipe]
autostartserverpath="C:\Program Files (x86)\ISE\ISEntial\dbnt5sv.exe"
serverpath=Server8

Obwohl im Abschnitt "[win32client.dll]" die Zeile "comdll=sqlapipe" auskommentiert ist, wird schwachsinnigerweise der Versuch unternommen, den Datenbankserver zu starten. Kommentiere ich im Abschnitt "[win32client.apipe]" beide nachfolgende Zeilen aus, funktioniert alles.

Das habe ich jedoch beim Kunden noch nicht getestet, aber den Gegenbeweis bei mir angetreten, indem ich in der angeblich vom .NET-Dataprovider nicht mehr benötigten "sql.ini" die Zeilen eingefügt bzw. aktiviert habe – dann habe ich genau dasselbe Verhalten wie beim Kunden.

Die Datei "sql.ini" kann ich leider nicht entsorgen, da sie von einer anderen Anwendungen (native Anwendung, kein .NET-Dataprovider) verwendet wird. Aber durch Auskommentieren beider Zeilen müsste der Fehler weg sein.

Nochmals vielen Dank!

Die Datenbank bzw. deren Client soll neuerdings ohne die berühmte Datei "sql.ini" funktionieren

Das ist nicht richtig interpretiert.
Der Client geht auch wenn die Datei nicht da ist, aber wenn sie da ist, wird sie auch benutzt.

Ja, Gupta/Centura/Unify/wieder Gupta/OpenText muss man interpretieren:

Trotzt vollständigen Connectionstring und in der sql.ini ausgeschalteter "sqlapipe" wird der Versuch unternommen, in der dafür zuständigen Sektion ein Datenbankserver zu starten.

Das hat uns unheimlich viel Arbeit und Nerven gekostet.

Darfst du auch .NET-Anwendungen für SQLBase entwickeln oder gar direkt mit Team Developer? Keine gute Erfahrungen?

Team Developer. Version 2005. (Mehr muss man nicht sagen, glaub ich 😉 )

LaTino

Verstehe 😉

Wir zum Teil immer noch mit dem Urahn CTD 1.12, wobei wir zurzeit den Umstieg auf TD 6 vollziehen. Dabei versuchen wir jedoch so viel wie möglich mit C# zu machen, um uns nicht weiter an das System zu binden.