ALTER Procedure hängt

[tom-kuehn]

Moin zusammen,
ich habe ein sehr merkwürdiges Phänomen auf einem SQL Server 2019.
Ein "create procedure" bleibt einfach so hängen. Gibt es da irgendeine Größenbeschränkung? Syntax ist definitiv in Ordnung, wird da noch irgend geprüft? Beim Create wird swiw ja noch nichts ausgeführt.
Beim Ausführen wird nur angezeigt: "Anfrage wird ausgeführt" und dann passiert nichts mehr.
Hat hier irgend jemand eine Idee?

Viele Grüße
Thomas

USE [BI]
GO
/****** Object: StoredProcedure [dbo].[ImportVorgangarchiv] Script Date: 10.08.2020 10:56:24 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: Thomas Kühn
-- Create date: 10.08.2020
-- Description: Importiert neue vorgangarchiv aus der Postgres Datenbank
-- =============================================
ALTER PROCEDURE [dbo].[ImportVorgangArchiv]
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;


DECLARE @TSQL varchar(max), @VAR char(50);

IF OBJECT_ID('tempdb..#belegnummern') IS NOT NULL DROP TABLE #belegnummern;
-- Ermittelt alle noch nicht importierten vorgangarchiv Datensätze

select belegnr into #belegnummern
from kobalt_bi.kobalt.c1.vorgangarchiv
where belegnr not in (select belegnr from dbo.vorgangarchiv);

DECLARE cur CURSOR FOR
SELECT belegnr from #belegnummern;

OPEN cur
FETCH NEXT FROM cur
INTO @VAR;

WHILE @@FETCH_STATUS = 0
BEGIN

SELECT @TSQL = 'insert into dbo.vorgangarchiv
SELECT * FROM OPENQUERY(kobalt_bi,''select
aadgrp,
abwwdlvogkz,
adrnr,
adrnrinfo,
aendbzr,
aenddat,
ansnr,
art,
artimg,
artprgrp,
aucwebid,
auftrnr,
ausgvtlkz,
auslkdeukz,
auslkdkz,
aznksbet,
aznksmge,
azpakete,
bawfak,
belegnr,
belegnrinbarcodelistekz,
belegposnr,
bez,
bic,
bkkubez,
bktonr,
blz,
blznr,
bnkvb,
buchtinfo,
dat,
dreigskz,
erledigtkz,
erstbzr,
erstdat,
exportkz,
facttext,
facttextkz,
frachtbet,
frwfak,
fvtrgrp,
gaebkz,
garepreisbt,
garepreisnt,
garepreisst,
gebuchtkz,
gedrucktkz,
gefaxtkz,
gekkalk,
gekroh,
gekrohl1,
gekrohl1s,
gemailtkz,
gewverteil,
ggew,
ggutscheinabbt,
ggutscheinabnt,
ggutscheinabst,
ggutscheinzubt,
ggutscheinzunt,
ggutscheinzust,
gopbt,
gopnt,
gopst,
grohbet,
grohsz,
grp,
grpbuch,
gsktobt,
gsktont,
gsktost,
gspdat,
gspgrp,
gspinfo::varchar(10485760),
gspinfokz,
gspkz,
histkz,
hybzr,
hydat,
hyinfo,
iban,
id,
iklstkz,
info::varchar(10485760),
infokz,
inhab,
kalk_diffkalkkz,
kalk_hkzus,
kalk_lantsz,
kalk_lkgrp,
kalk_llbet,
kalk_llzteh,
kalk_lzt,
kalk_lzteh,
kalk_lzus1,
kalk_mantsz,
kalk_mekzus1,
kalk_mekzus2,
kalk_mekzus3,
kalk_mkgrp,
kalk_mksz,
kalk_mzus,
kalk_pfgrp,
kalk_provsz,
kalk_rabsz,
kalk_schema,
kalk_skkgrp,
kalk_skksz,
kalk_sktosz,
kalk_skzus,
kaprovkz,
kartart,
kartgueltig,
kartinhab,
kartnr,
kdbezbet,
kdliefnr,
kdrabgrpwgr,
knr,
kredlimit,
kstnr,
kstnrinfo,
lastbetl1,
lastdat,
lfdtznr,
liadrnr,
liansnr,
liansvwkz,
liaspabt,
liaspanr,
liaspanrsb,
liaspansp,
liaspebis1,
liaspebis2,
liaspemail1,
liaspemail2,
liaspevon1,
liaspevon2,
liaspevonbis1,
liaspevonbis2,
liaspfax,
liaspmtel,
liaspnazus,
liaspnna,
liasppos,
liasptel1,
liasptel2,
liasptit,
liaspverteiler,
liaspvna,
liaspvswort,
liefbed,
liefdat,
liemail1,
liemail2,
lifax,
lifznr,
liiln,
liland,
lilandbez,
lilandkennz,
lilcmanuellkz,
lileitcode,
lina1,
lina2,
lina3,
liort,
lipfort,
lipfplz,
liplz,
liplzinfo,
liplzortinfo,
lipostf,
listr,
litel,
liverteiler,
ltzaend,
ltzart,
mandatgueltigkz,
mandatref,
mandatrefinfo,
memo::varchar(10485760),
memokz,
nachlbet,
nachtext::varchar(10485760),
nachtextkz,
nettotg,
opsumreadrnr,
pnuebermittelnkz,
prjnr,
prjnrinfo,
rabkz,
rabsz,
rbetprnakz,
reansvwkz,
reaspabt,
reaspanr,
reaspanrsb,
reaspansp,
reaspebis1,
reaspebis2,
reaspemail1,
reaspemail2,
reaspevon1,
reaspevon2,
reaspevonbis1,
reaspevonbis2,
reaspfax,
reaspmtel,
reaspnazus,
reaspnna,
reasppos,
reasptel1,
reasptel2,
reasptit,
reaspverteiler,
reaspvna,
reaspvswort,
reemail1,
reemail2,
refax,
refznr,
reiln,
reland,
relandbez,
relandkennz,
relcmanuellkz,
releitcode,
rena1,
rena2,
rena3,
reort,
repfort,
repfplz,
replz,
replzinfo,
replzortinfo,
repostf,
restr,
retel,
reverteiler,
sepalastschkz,
sktobrtbet,
sktosz1,
sktosz2,
sktotg1,
sktotg2,
stgeschkz,
storniertkz,
suchbeg,
svtabraendkz,
svtabrzyk,
syszahlart,
teilliefinfo,
teilliefkz,
textflags,
textkz1,
textkz10,
textkz11,
textkz12,
textkz13,
textkz14,
textkz15,
textkz16,
textkz17,
textkz18,
textkz19,
textkz2,
textkz20,
textkz21,
textkz22,
textkz23,
textkz24,
textkz25,
textkz26,
textkz27,
textkz28,
textkz29,
textkz3,
textkz30,
textkz4,
textkz5,
textkz6,
textkz7,
textkz8,
textkz9,
tlbgazpos,
tlbggew,
tlbgmge,
tlbgwwertbrt,
tlbgwwertnt,
tlbinfo,
tlbinfoimg,
tlbliefazpos,
tlbliefazposk,
tlbliefgew,
tlbliefmge,
tlbliefwwertbrt,
tlbliefwwertnt,
tlbrueckazpos,
tlbrueckgew,
tlbrueckmge,
tlbrueckwwertbrt,
tlbrueckwwertnt,
tlbsz,
transaktnr,
umsekroh,
umsnetto,
ustid,
ustkat,
ustkatmkz,
valutadat,
valutatg,
verk,
verkinfo,
versichkz,
vfgrpsum0buchmge,
vfgrpsum0gew,
vfgrpsum0preis,
vortext::varchar(10485760),
vortextkz,
vsdart,
vsdzweise,
vswertbet,
vtrgrpvtrnr,
vtrgrpvtrnrinfo,
vtrnr,
vtrnrinfo,
vtrprovsz,
waehr,
wshopid,
zahlart,
zahlbed,
zahlhbk,
zahlhbkbic,
zahlhbkblz,
zahlhbkblznr,
zahlhbkiban,
zahlhbkinhab,
zahlhbkknr,
zugpktnr,
kbversion,
kberpvers,
kbnode,
kbsync,
kbsyncts1,
kbsyncts2,
kbreplts,
kbcheck1,
kbcheck2,
kbgc1,
kbgc2,
kbts,
zahlhbkqriban
from c1.vorgangarchiv WHERE belegnr = ''''' + TRIM(@VAR) + ''''''')';
--print @VAR;
EXEC (@TSQL);


FETCH NEXT FROM cur
INTO @VAR;
END

CLOSE cur;
DEALLOCATE cur;

DROP TABLE #belegnummern;

END

 

[dabadepdu]

ich habe ein sehr merkwürdiges Phänomen auf einem SQL Server 2019.
Ein "create procedure" bleibt einfach so hängen. Gibt es da irgendeine Größenbeschränkung?

Ich sag mal so, wieso sollte eine teure Kaufsoftware sowas nicht können?
(wieso benutzt man sowas überhaupt für Archivierung?)

Ich kenne Openquery nicht, aber es scheint mir hier naheliegend, als erstes die Verbindung zum anderen System zu überprüfen. Einfachster Ansatz, ein kleine, einfache Abfrage absetzen, die per se funktionieren muss (also Abfrage einer Systemtabelle oder bloß einer Funktion ohne Tabelle).
Ebenso wäre es denkbar, die Abfrage probehalber ohne Prozedurkapselung und mit festem Parameter zu starten.

 

[akretschmer]

wenn da auf der Gegenseite eine PostgreSQL-DB ist, auch mal dort schauen, ob da was im Log steht.

 

[tom-kuehn]

Ich kenne Openquery nicht, aber es scheint mir hier naheliegend, als erstes die Verbindung zum anderen System zu überprüfen. Einfachster Ansatz, ein kleine, einfache Abfrage absetzen, die per se funktionieren muss (also Abfrage einer Systemtabelle oder bloß einer Funktion ohne Tabelle).
Ebenso wäre es denkbar, die Abfrage probehalber ohne Prozedurkapselung und mit festem Parameter zu starten.

Die Verbindung zum Postgres Server steht. Einfache Abfragen laufen ohne Probleme. Deinen Vorschlag hatte ich vor der Prozedurerstellung schon umgesetzt und da lief es eben. Deshalb bin ich so verwundert, dass die Erstellung der Procedure nicht klappt.

 

[tom-kuehn]

wenn da auf der Gegenseite eine PostgreSQL-DB ist, auch mal dort schauen, ob da was im Log steht.

Auch eine Idee. Ich habe hier nur den pgAdmin auf dem Browser laufen und kenne mich mit Postgres nicht wirklich aus. Wo kann man denn hier LOgs anschauen?

 

[castorp]

Das könnte auch durch ein anderes DDL Statement verursacht werden, das nicht committed wurde.
SQL Server wartet dann auf den Lock der System-Tabellen damit das ALTER PROCEDURE ausgeführt werden kann.

Kannst Du sicherstellen, dass keine andere Verbindung zum SQL Server offen ist (oder alternativ in alle offenen Verbindungen ein COMMIT absetzen)

 

[akretschmer]

Wo kann man denn hier LOgs anschauen

die stehen per default im pg_log - Verzeichniss. Aber vermutlich hat @castorp Recht.

 

[tom-kuehn]

Das könnte auch durch ein anderes DDL Statement verursacht werden, das nicht committed wurde.
SQL Server wartet dann auf den Lock der System-Tabellen damit das ALTER PROCEDURE ausgeführt werden kann.

Ich bin als einziger auf der Datenbank und habe sonst nichts laufen

Kannst Du sicherstellen, dass keine andere Verbindung zum SQL Server offen ist (oder alternativ in alle offenen Verbindungen ein COMMIT absetzen)

Ich könnte die DB auf Single_user stellen, da aber außer mir keiner auf der Datenbank ist, weiß ich nicht ob das was bringt.

 

[tom-kuehn]

die stehen per default im pg_log - Verzeichniss. Aber vermutlich hat @castorp Recht.

Gefunden, aber da steht nichts drin.

 

[castorp]

Ich bin als einziger auf der Datenbank und habe sonst nichts laufen


Ich könnte die DB auf Single_user stellen, da aber außer mir keiner auf der Datenbank ist, weiß ich nicht ob das was bringt.

Wenn das Statement hängt, verbinde Dich ein zweites Mal, und dann schau z.B. via sp_who2 nach ob Dein DDL Statement ge-blocked ist, und wenn ja von welcher Session.

 

[tom-kuehn]

Da ist leider nichts geblockt. Es gibt nur zwei Prozesse auf der DB. Einmal das CREATE PROCEDURE und dann der sp_who2 Aufruf.

 

[dabadepdu]

Wenn es keine Locks auf keiner Seite gibt (und keine Timeout? > eine Timeout Message könnte einen brauchbaren HInweis liefern, wer da klemmt), dann musst Du dich heran tasten.
- Das nackte Statement testen
und je nach dem was geht
-> das Statement in der Proc stück für Stück halbieren, bis es läuft
Einfache Statements gehen ja, sagst Du.
Falls es einen Mittelweg gibt, der funktioniert, mit den ausgelassenen Teilen experimentieren.
Vielleicht liegen besondere Datentypen vor, Datumswerte sind z.B. gerne ein Problem bei Extremwerten, BLOB natürlich auch, generell jeder Typ von PG, der bei MSSQL so nicht existiert.
Du kannst das Spiel auch mit Daten machen.
Einen "ordentlichen", unauffälligen Testdatensatz anlegen und versuchen, ob es damit geht.
(Soetwas macht wahrscheinlich keinen Sinn, Ausnahme: wenn Openquery seltsame Dinge tut, um Kenntnis über die Datenstruktur zu erlangen, die da aufgerufen wird)