Service auf entfernte DB, UPDATE permission denied on column

Question

Hi,

Habe ein Windows-Service mit VB.NET entwickelt, der mit dem lokalen Systemkonto läuft.
Darin habe ich ein Dataset, bei dem ich im Code die Tables lese und schreiben (möchte).

Im Entwicklungscomputer funktioniert das Programm tadellos, die DB ist lokal eingerichtet, der Connectionsstring beinhaltet einen definierten User mit Vollzugriff auf die DB (owner).

Nun habe ich den Service neu auf einen Server eingerichtet, die DB ist auf einem anderen SQL-Server. Der User im Connectionstring hat auch Vollzugriff auf die DB.

Der Service kann die Daten lesen mittels (Datensatz ist vorhanden):

Dim _MT_InfoPersonTableAdapter As New DS_FertiMedTableAdapters.MT_InfoPersonTableAdapter
Dim _MT_InfoPersonDataTable As New DS_FertiMed.MT_InfoPersonDataTable
_MT_InfoPersonDataTable = _MT_InfoPersonTableAdapter.GetDataByPID(„123“)

 Wenn ich nun die Daten im Datatable mittels _MT_InfoPersonTableAdapter.Update(_MT_InfoPersonDataTable)
Speichern möchte, erhalte ich die Fehlermeldung für alle Fields:

UPDATE permission denied on column 'Nachname' of object 'MT_InfoPerson', database 'MeineDatenbank', owner 'dbo'.
....

Ich kann mich auf dem Server mittels dem SQL-Manager auf den SQL-Server mittels diesem User anmelden und Daten in dieser Tabelle ändern.

Wo liegt das Problem mit der Berechtigung?

Gruss und Dank
Philippe

Nun habe ich weitere Tests gemacht.
Auf meinem Entwicklungscomputer kann ich auf meinem eigenen SQL-Server per Remote zugreifen. Also das gleiche Vorgehen wie auf dem oben erwähnten Server. Auch ohne gleiche Domainuser auf den zwei Rechnern.

Zudem laufen Anwendungen auf den Clients, die auf den SQL-Server (mittels ODBC) Zugreifen, also keine Services. Funktioniert.

Ich versuche es nun mal mit ODBC, denn ich benutze den System.Data.SqlClient im Connectionsstring.

Könnte es sein, dass da die Policiy mitspielt?

Answer 1

Hallo Philippe,

schau Dir mal an: Testing connection to SQL Server from a service running under Local System Account

Im allgemeinen ist es besser, ein Domänen-Konto für einen Windows Dienst einzurichten,
so wie es auch für den SQL Server empfohlen wird, siehe dort Windows Dienstkonten

Gruß Elmar

 

Answer 2

Hi Elmar

Danke für deine Bemühungen!

Nun, das Dokument Testing connection to SQL Server from a service running under Local System Account bezieht sich (eher) auf Verbindungen mittels einer Trustet Connection. Im zweiten Dokument sehe ich keine Lösungsmöglichkeiten.

Dennoch habe ich auch den (ServiceServer) LocalSystem im remote SQL-Server eingefügt, gleiche Fehlermeldung.
Weiter habe ich den Service als normales (Standalone) Programm umgeschrieben und gestartet, gleiche Fehlermeldung.

Auch mit ODBC habe ich Probleme, im Dataset kann ich keine Parameter (für Where) angeben…
Bin echt am verzweifeln!!

Sicherheitshalber nenne ich noch die Systeme:

"Service" Server: Windows 2008

Remote Server: Windows 2000 (mit dem SQL-Server)

Remote SQL-Server: Version Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)

Die Windows-Anmelde-Kontos sind in einer Domäne, kann jegliches mit Trusted Connection öffnen (SQL-Manager), lesen und schreiben, egal wo, ausser eben mit einem von mir geschriebenen Applikation.

Ich kann nicht verstehen, wieso ich mittels meiner Applikation überhaupt Daten lesen aber nicht schreiben kann.
Auf meinem System (mit Remote SQL-Server 2008R2 Express) funktioniert die Applikation problemlos.

Was kann ich noch probieren?

Answer 3

Habe noch ein neues einfaches standalone Programm geschrieben, welche mit einer Sqlconnection erfolgreich connected, aber auch kein Update mittels SQLcommand erfolgreich durchführt. Somit kann ich ein Fehler in meinem Service ausschliessen.

Desweiteren funktioniert es auch nicht, wenn ich beim Kunden vom ServiceServer auf einen anderen remote SQL-Server 2008 zugreife.

Es müsste also ein Problem auf dem ServiceServer geben.
Firewall ist auch offen, für den Fall ;-)

Werde der IT dort mal anrufen, ob es auf der VM irgendwelche Eingrenzungen gibt, was ich aber nicht glaube.

Folgende Fehlermeldung.

System.Data.SqlClient.SqlException: UPDATE permission denied on column 'Austrittsart' of object 'MT_InfoPerson', database 'MyDatabase', owner 'dbo'.
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async)
   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at ImportServiceSelectcommandTest.Form1.Button1_Click(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Answer 4

Hallo Philippe,

zunächst einmal wäre dringend eine Aktualisierung des SQL Servers von Nöten,
denn das Service Pack 3 (8.0.760) ist nun seit Jahren veraltet.
SQL Server 2000 Service Pack 4 gehört installiert - und das letzte Security Update sollte es auch,
da auch dort Korrekturen (abseits kritischer Fehler) vorgenommen wurden.

Das Windows 2000 aus dem Support ist, wollen wir zunächst ignorieren,
aber Probleme mit Windows 2008 sind nicht ausgeschlossen.

Zum Problem selbst:
Da ich Deine Konfiguration aus der Beschreibung nur erahnen kann,
vermute ich dass Du eben nicht dem Konto auf dem Server landest,
was Du erwartest.

Und das Dein lesender Zugriff über eine allgemeine Datenbankrolle wie db_datareader
erfolgreich ist, aber jeglicher schreibende Zugriff eben nicht.

Um zu prüfen, mit welchem Konto Du da überhaupt arbeitest,
führe aus Deinem Dienst (ExecuteReader oder zwei ExecuteScalar reichen aus):

SELECT SUSER_SNAME() AS SUserName, USER_NAME() AS UserName

Deine ODBC Probleme müsstest Du schon präzisieren, das gibt für mich derzeit überhaupt keinen Sinn.
Oder verwende den SqlClient, was eh das sinnvollste ist.

Gruß Elmar

 

Answer 5

Hi Elmar

Danke für deine Bemühungen.

Dieser alte SQL-Server wird eben abgelöst. Auch habe ich nicht die Verantwortung über diesen Server.
Der alte "Import"Service läuft nicht mehr auf dem neuen ServiceServer. Für das Schrittweise ablösen, muss der neue Service die alten FlatfileDaten noch auf den alten SQL-Server schreiben.

Mein kleines standalone Programm (Sqlconnection, Sqlcommand) habe ich zum laufen bekommen, dass er Daten schreibt, indem ich den Connectionsstring abgeändert habe:

"Data Source=myserver;Initial Catalog=MyDB;Persist Security Info=True;User ID=myuser;Password=mypass"

nach

"Server=myserver;Database=mydb;Trusted_Connection=True"

Wenn ich nun im Service den Connectionstring ändere, bleibt der aber trotzdem am Update hängen, ohne Fehlermeldung.
Muss wohl lokal auf dem ServiceServer debuggen, oder das Programm umschreiben.

Answer 6

Hallo Philippe,

wenn Du mit Trusted_Connection=true zugreifst, so verwendest Du
Windows Authentifizierung, und so trifft der anfangs genannte Artikel voll auf Dich zu!

Das Hängenbleiben wäre schon mal besser als eine Fehlermeldung.
Auch da kämst Du vermutlich weiter, wenn Du zunächst einmal in einem Testprogramm
eine Änderung einbaust, die ähnlich der im Dienst ist.

Gruß Elmar

Answer 7

Hi Elmar

"wenn Du mit Trusted_Connection=true zugreifst, so verwendest Du 
 Windows Authentifizierung, und so trifft der anfangs genannte Artikel voll auf Dich zu!"

Das stimmt. (Wobei ich ja dieses System konto im/beim SQL-Server registriert habe ;-)

Im Service, unter app.config,  habe ich den providerName="System.Data.SqlClient".

Meines Wissens (in meinem Testprogramm) benutzt der Dim conn As New SqlConnection() auch den SqlClient. Oder?

Den Service habe ich als Testprogramm realisiert gehabt, hat nicht funktioniert.

Werde anfragen, ob ich dort VB.net installieren kann, zum debuggen. Sonst verliere ich noch mehr Zeit.

Gruss und Dank.

 

Answer 8

Hi Elmar

Ich habe den Fehler gefunden :-)))

Ich habe mit dem SQL-Profiler und dem Queryanalyzer gespielt und dabei folgendes festgestellt.

Die Datenbank und die StandaloneProgramms habe ich etwa um die Zeit 1996 geschrieben, für mehrere Spitäler.
In allen Spitäler hat dieser Userx DB owner Berechtigung, ausser in diesem Spital.
In diesem Spital laufen die StandaloneProgramme unter TrustedConnection.

Nun habe ich dazumal diesen Userx in eine bestimmte DB-Rolle getan, welche nur beschränkt Zugriff hat, genau auf diese Tabelle. Das wusste ich nicht mehr.

Es tut mir leid für den Aufwand den du für mich aufgewendet hast.
Nochmals, herzlichen Dank für deine Bemühungen.

Mein Fehler, sorry.

Gruss und Dank
Philippe