OPENROWSET Fehler - Objekt hat keine Spalten

[ukulele]

Ich teste ein paar Ideen und habe eigentlich einen sehr simplen Aufbau. Weil aber heute Montag ist scheitere ich an einer total dummen Sache nur ich checks offenbar nicht.

USE dbdb;

sp_configure 'Show Advanced Options', 1
GO
RECONFIGURE
GO
sp_configure 'Ad Hoc Distributed Queries', 1
GO
RECONFIGURE
GO

--DROP TABLE tbl_bit;
CREATE TABLE [tbl_bit](
    [bit] INT NOT NULL,
    [notbit] VARCHAR(10) NOT NULL
    );
INSERT INTO tbl_bit([bit],[notbit]) VALUES (1,'test');

CREATE TABLE [tbl_test](
    [timestamp] DATETIME NOT NULL,
    [user] VARCHAR(100) NULL,
    [object] VARCHAR(100) NULL
    );

--DROP PROCEDURE sp_test;
CREATE PROCEDURE sp_test
AS
INSERT INTO tbl_test([timestamp],[user],[object]) VALUES (getdate(),SYSTEM_USER,'sp_test')
SELECT * FROM tbl_bit
GO

So weit so gut. Es gibt eine Tabelle tbl_bit, die soll einfach nur irgendeinen Wert liefern. Wenn die Prozedur sp_test aufgerufen wird soll in tbl_test etwas rein geschrieben werden und dieser Wert aus tbl_bit zurück gegeben werden. Klappt auch mit

EXEC [dbo].[sp_test];

bekomme ich 1 test zurück und in tbl_test wird der Vorgang rein geschrieben. Wenn ich jetzt aber versuche mit OPENROWQUERY eines der folgenden Statements abzusetzen scheitert das:

SELECT    *
FROM    OPENROWSET(    'SQLNCLI','server=localhost;trusted_connection=yes;',
                    'EXEC [dbdb].[dbo].[sp_test]' ) sp
SELECT    *
FROM    OPENROWSET(    'SQLNCLI', 'Server=localhost;UID=sa;PWD=******;',
                    'EXEC [dbdb].[dbo].[sp_test]' ) sp

Msg 7357, Level 16, State 1, Line 37
Das EXEC [dbdb].[dbo].[sp_test]-Objekt kann nicht verarbeitet werden. Der OLE DB-Anbieter "MSOLEDBSQL" für den Verbindungsserver "(null)" zeigt an, dass entweder das Objekt keine Spalten aufweist oder der aktuelle Benutzer keine Berechtigungen für dieses Objekt besitzt.

Berechtigungen müssten vorhanden sein, ich habe extra eine Tabelle erstellt mit Spaltennamen und Datentyp, ich weiß nicht ob die Meldung nicht einfach Blödsinn ist. Nehme ich den INSERT aus der Prozedur raus geht der Aufruf und das Ergebnis kommt zurück. Der Aufruf über OPENROWSET einer anderen, viel komplizierteren Prozedur die auch Daten zurück liefert, funktioniert. Die sollte auch einen INSERT machen, der wird aber einfach "verschluckt".

Die Grundidee ist, Aufrufe einer View zu dokumentieren um später die Daten aufgrund von Aufrufen im Hintergrund zu aktuallisieren. Das geht grundsätzlich mit über SPs, aber ich brauche halt für die Anwendung eine Tabelle oder eine View und ich muss irgendwie irgendwas irgendwo hin schreiben damit ein Job oder sonstwas nachvollziehen kann das es was zu tun gibt.

SQL SERVER - Using Stored Procedure in SELECT Statement - SQL Authority with Pinal Dave

A very popular question I often receive during my Performance Health Check is about how to use stored procedures in SELECT Statement.

blog.sqlauthority.com

 

[ukulele]

Ah natürlich, die Reihenfolge macht den Unterschied. Der Select aus der SP klappt. Steht der an erster Stelle gibts auch keinen Fehler. Der INSERT klappt allerdings nicht, vermutlich wirft der dann den Fehler. Stellt sich die Frage warum ein Insert generell nicht ausgeführt werden kann aus einer SP, die über OPENROWSET aufgerufen wird.

 

[t-sql]

MSSQLSERVER_7357 - SQL Server

MSSQLSERVER_7357

learn.microsoft.com

 

[ukulele]

Ich habe jetzt mal testweise [servername].[database].[schema].[objektname] genutzt, sowohl in der SP als auch beim Aufruf der SP über OPENROWSET. Leider hat das nichts geändert.

a) Muss in der Reihenfolge der Select in der SP vor dem Insert stehen und b) funktioniert der Insert dann nur wenn ich die SP mit EXEC aufrufe, nicht wenn ich sie über OPENROWSET aufrufe.

Mir scheint das ist eine Sackgasse und ich hab auch keine Idee mehr wie man einen Select und einen Insert kombiniert durch eine View veranlassen könnte.