Goos

Nein, das geht nicht. Weshalb magst das tun? Goos

Die Frage ist nicht ausreichend genau formuliert. Asynchron wozu bitte? Goos

Eine aehnliche Paging-Funktion wird es erst im SQL Server 2011 geben. Bislang kann man sich beispielsweise ueber die ROW_NUMBER() Funktion behelfen. Goos

Du hast vergessen dein DBS zu benennen. Goos

Vielleicht verwendest du keinen gelben Strom Viel mehr lässt sich mit den gegebenen Informationen nicht sagen. Mit grosser Wahrscheinlichkeit hast du aber Lockingprobleme und verwendest für deine 5000 Inserts implizite Transaktionen. Goos

Das funktioniert mit: WITH XMLNAMESPACES( DEFAULT 'http://DbToSap') SELECT * FROM Epc WHERE Code = @ID FOR XML AUTO Goos

Ok, ich habs begriffen. Ich weiss aber nicht was du eigentlich machen wolltest Es ist in jedem Fall problematisch, wenn dein "declare @SELECT varchar(max)" innerhalb deiner While-Schleife in jedem Durchlauf neu angelegt wird. Ich vermute, dass du das nicht so vorhattest. Goos

Ach das ist wirklich nur das, was deine Prozedur per print ausgibt und nun soll man raten was in der Prozedur falsch läuft? Ist das in etwa sowas wie: Das Ergebnis lautet 42, wie war die Aufgabenstellung und welche Intention hatte der Autor? Goos PS: ..oder hab ichs schon wieder nicht verstanden?

Hi Brodi87, ich kann dir nicht wirklich folgen. Wieso schreibst du von einer Fehlermeldung, postest im Anschluss aber zwei Stück und davon dann die eine auch noch mitten in dein Satement rein? Versuch doch dein Problem nochmal etwas präziser zu erläutern. Goos

Ich wüsste nicht wo es da einen Haken geben sollte. Es müssen ein Minimal- und ein Maximalwert gesetzt werden. Ich geh den bisherigen Beschreibungen nach auch nicht davon aus, dass es am Hauptspeicher liegt, aber wer weiss Du kannst mit folgendem Statement mal die üblichen Verdächtigen unter den Waitstatistiken abprüfen: SELECT wait_type ,waiting_tasks_count ,wait_time_ms ,max_wait_time_ms FROM sys.dm_os_wait_stats WHERE wait_type LIKE 'Resource%' OR wait_type LIKE 'CMEMTHREAD%' OR wait_type LIKE 'Latch%' OR wait_type LIKE 'PAGE%' OR wait_type LIKE 'DBTABLE%' OR wait_type IN ('LOGBUFFER' ,'DISKIO_SUSPEND' ,'REQUEST_DISPENSER_PAUSE' ,'REPLICA_WRITES' ,'FCB_REPLICA_READ' ,'FCB_REPLICA_WRITE' ,'DBMIRROR_SEND' ,'ASYNC_NETWORK_IO' ,'ASYNC_IO_COMPLETION' ,'WRITEBUFFER' ,'IMPPROV_IOWAIT' ,'IO_COMPLETION' ,'SOAP_READ' ,'SOAP_WRITE') ORDER BY wait_time_ms DESC Weiterhin würde ich dir empfehlen, die Waitstatistiken für Locks anzuschaun. SELECT wait_type ,waiting_tasks_count ,wait_time_ms ,max_wait_time_ms FROM sys.dm_os_wait_stats WHERE wait_type LIKE 'LCK%' Falls der Server allerdings schon sehr lange läuft, solltest du die Waitstats auch mal zurücksetzen. Sie werden nämlich durch Sonderaufgaben wie z.B. Indexrebuilds gerne mal verfälscht. Goos

Hi streffin, Scheinbar kommt hier nicht so recht an was ich ausdrücken wollte. Im ersten Vergleich hab ich herausstellen wollen, dass ein Join zum Erstellen einer Nummerntabelle performanter ist als eine Schleife (Der Geschwindigkeitsvorteil steigt hier mit der Menge der generierten Nummern). Im Zweiten Beispiel ging es mir allein um die Vorteile des Join anstelle der Schleife um entsprechende Duplikate zu erzeugen. Auch hier gewinnt der Join mit zunehmender Menge der generierten Daten ganz deutlich, ist aber im Gegenzug nie wirklich langsamer als die Schleife. Die dabei verwendete Art der Nummerngenerierung ist sicherlich auch mit Nachteilen behaftet, eignet sich aber zu Beispielzwecken besser als eine grosse, statische Nummerntabelle. Wie in meinem vorherigen Beitrag schon erwähnt würde ich der Performance wegen aber eine indizierte Nummerntabelle mit einigen Millionen Nummern bevorzugen. Im Falle der Etiketten braucht man sich dann keinerlei Sorgen wegen eines Überlaufs machen, obwohl dein Einwand sonst natürlich gerechtfertigt ist und evtl. eine gesonderte Überprüfung erfordert. Diese Optimierungsversprechen halte ich für aus der Luft gegriffen. Zumindest behaupte ich, dass es dir nicht gelingen wird, meinen Ansatz (abgesehen von der schon erwähnten, indizierten Nummerntabelle) noch nennenswert zu beschleunigen. (Faktor < 0,7) Wenn du magst, kannst du es aber gerne versuchen. Ich bin konstruktiven Vorschlägen gegenüber immer aufgeschlossen PS: Meine MS SQLServer laufen allesamt auf meinem Notebook Goos

Prinzipiell ging es mir bei meinem Ansatz aber nicht um die Generierung der Nummerntabelle. Im Idealfall besitzt die entsprechende Datenbank ja schon eine relativ grosse, indizierte Nummerntabelle. Ich wollte eigentlich eher die Vorteile des mengenbasierten Joins gegenüber der prozeduralen Cursorlösung herausstellen. Dazu hier ein Vergleichsbeispiel welches 15000 Zeilen generiert. Cursorbasierter Ansatz: 1743 ms Mengenbasierter Ansatz: 386 ms DECLARE @start DATETIME DECLARE @stop DATETIME IF OBJECT_ID('tempdb.dbo.#temp') > 0 BEGIN DROP TABLE #temp END IF OBJECT_ID('tempdb.dbo.#test') > 0 BEGIN DROP TABLE #test END CREATE TABLE #test (bezeichnung NVARCHAR(255), menge INT) INSERT INTO #test VALUES ('apfel', 5000) , ('birne', 10000) DECLARE @bezeichnung NVARCHAR(255) DECLARE @anzahl INT CREATE TABLE #temp (id INT NOT NULL, bezeichnung NVARCHAR(255)) SET @start = CURRENT_TIMESTAMP --Cursorbasierter prozeduraler Ansatz von streffin DECLARE curs CURSOR FOR SELECT bezeichnung, menge FROM #test OPEN curs FETCH NEXT FROM curs INTO @bezeichnung, @anzahl WHILE @@FETCH_STATUS <> -1 BEGIN WHILE @anzahl > 0 BEGIN INSERT INTO #temp VALUES (@anzahl, @bezeichnung) SET @anzahl = @anzahl -1 END FETCH NEXT FROM curs INTO @bezeichnung, @anzahl END SELECT * FROM #temp SET @stop = CURRENT_TIMESTAMP SELECT DATEDIFF(ms, @start, @stop) CLOSE curs DEALLOCATE curs --Mengenbasierter Ansatz mit generierter Nummerntabelle SET @start = CURRENT_TIMESTAMP; WITH numbercte(number) AS ( SELECT TOP 50000 ROW_NUMBER() OVER( ORDER BY a.number) FROM master..spt_values AS A INNER JOIN master..spt_values AS B ON a.Type = 'P' ) SELECT Bezeichnung, Menge FROM #test a JOIN numbercte ON a.menge >= numbercte.number ORDER BY Bezeichnung SET @stop = CURRENT_TIMESTAMP SELECT DATEDIFF(ms, @start, @stop) Goos

Solltest du aber tun. Der Ansatz, eine temp Tabelle in einer Schleife mit aufsteigenden Zahlen zu füllen ist so ziemlich der schlechtestmögliche. Im folgenden Beispiel gewinnt mein mengenbasierter Ansatz (Systemtabellen joinen) gegenüber der prozeduralen Lösung (Schleife) schon bei 9999 Nummern um Längen. Systemtabellen Join: 233 ms Schleife: 2510 ms SET STATISTICS TIME ON DECLARE @i INT DECLARE @start DATETIME DECLARE @stop DATETIME SET @i = 1 CREATE TABLE #numbers (i INT) --Prozedurale Erzeugung der Nummerntabelle SET @start = CURRENT_TIMESTAMP WHILE @i < 9999 BEGIN INSERT #numbers SELECT @i SET @i = @i +1 END select i from #numbers SET @stop = CURRENT_TIMESTAMP SELECT DATEDIFF(ms, @start, @stop) DROP TABLE #numbers --Mengenbasierte Generierung der Nummerntabelle SET @start = CURRENT_TIMESTAMP; WITH numbercte(number) AS ( SELECT TOP 9999 ROW_NUMBER() OVER( ORDER BY a.number) FROM master..spt_values AS A INNER JOIN master..spt_values AS B ON a.Type = 'P' ) select number from numbercte SET @stop = CURRENT_TIMESTAMP SELECT DATEDIFF(ms, @start, @stop) Goos

Das geht eleganter ohne Cursor - mit nem einzelnen Statement und dem Join auf eine Nummerntabelle. Die Nummerntabelle würd ich in dem Fall mal ad hoc erzeugen (insofern die Anzahl nicht zu gross wird). Ich gehe mal von streffins #test Tabelle aus und würde es dann mit folgendem Statement versuchen. (Das Beispiel funktioniert bis zu einer Anzahl von 9999 ... andernfalls muss die TOP Bedinung angepasst werden) WITH numbercte(number) AS ( SELECT TOP 9999 ROW_NUMBER() OVER( ORDER BY a.number) FROM master..spt_values AS A INNER JOIN master..spt_values AS B ON a.Type = 'P' ) SELECT Bezeichnung, Menge FROM #test a JOIN numbercte ON a.menge >= numbercte.number ORDER BY Bezeichnung Goos

Doch doch, HOLDLOCK hilft dir weiter. Du musst natürlich darauf achten, auch eine entsprechende Transaktion zu setzen. Alternativ zum HOLDLOCK Table Hint kannst du auch den Transaction Isolation Level für diese Transaktion auf SERIALIZABLE setzen. Der ROWLOCK Table Hint allein wird in deinem Fall nicht funktionieren. Du kannst allerdings über ROWLOCK in Verbindung mit XLOCK eine exklusive Sperre auf dem Datensatz setzen (Das verhindert für andere Benutzer dann aber auch die Anzeige des Datensatzes). Goos

Im inserted? Ich versteh deine Frage nicht wirklich. Falls du aber bei deinem Update eigentlich immer nur einen Datensatz erwischen wolltest, dann solltest du dein Update erstmal richtigstellen. Ob es gut ist, für Deine Logik einen Trigger einzusetzen ist im übrigen anzuzweifeln. Goos

easy_auftragsnr=169077 and easy_auf_lfdnr=1 ist in deinem Fall nicht eindeutig. Es werden mehrere Zeilen aktualisiert. In der Folge kommt es in deinem Trigger zu einem Problem, weil der Integervariable @FACHID gleich mehrere Werte zugewiesen werden sollen. Goos

Doch doch, dein Pushbutton ist schliesslich auch vom QWidget abgeleitet. Du solltest also von QPushButton ableiten und den erwähnten mouseDoubleClickEvent Handler implementieren. Goos

An der genannten Stelle steht trotzdem was deine Frage beantwortet. Du hasts nicht gelesen, oder nicht verstanden. Goos

Qt 4.7.0: QWidget Class Reference

Ich verzichte mal darauf irgendwelche Diskussionen über den Sinn der Anforderung anzuzetteln und behaupte, dass es nur die Möglichkeit über dynamisches SQL, oder alternativ eine CLR Funktion gibt. Mein Vorschlag ist folgender: DECLARE @Table SYSNAME DECLARE @cmd2 NVARCHAR(MAX) SET @Table = 't1' SELECT @cmd2 = N'SELECT ' + (STUFF((SELECT N' + '' '' + CAST(' + QUOTENAME(CAST(b.name AS SYSNAME)) + N' as VARCHAR(MAX))' FROM sysobjects a, syscolumns b WHERE a.type = 'U' AND a.id = b.id AND a.name = @Table FOR XML PATH('')),1,6,'')) + N' FROM ' + QUOTENAME(@Table) SELECT @cmd2 EXEC sp_executesql @cmd2 Man verzeihe mir die Verwendung der Aliase a und b Goos

Du solltest in dem Zusammenhang mal nach XQuery suchen. Damit kommst du zum Ziel, falls dein DBMS etwas entsprechendes unterstützt. Goos

Sowas gibt es so direkt nicht. Wer sich allerdings etwas intensiver mit der relationalen Theorie beschäftigt, wird früher oder später Werke von C.J. Date, oder auch Fabian Pascal lesen. Was man aus alledem dann praktisch macht ist in meinen Augen doch eher Erfahrungssache. Prinzipiell sollte man aber die Theorien kennen um zumindest genau zu wissen, weshalb man etwas so oder auch anders macht. Goos

Sowas ähnliches. Nannte sich MSDE 1.0 ... ich vermute aber, dass du das heute nirgends mehr beziehen kannst Goos

Hi citybreaker, deine Datenbank stammt von einer älteren non-release Version der SQL Server Datenbank. Der Buildnummer 515 nach würde ich mal so in Richtung SQL Server 7 tippen. Du wirst diese Datenbank auf direktem Wege nicht an einen 2008er Server anhängen können. Non-release Versionen von Datenbanken lassen sich in aller Regel nur an die entsprechende Release Version anhängen (aber auch das nicht in jedem Fall) Deine einzige Möglichkeit wäre also aller Wahrscheinlichkeit nach, einen SQL Server 7 zu installieren und die Datenbank erstmal dort anzuhängen. Goos PS: Wer arbeitet denn bitte mit Vorseriendatenbanken und hebt sie dann auch noch für spätere Verwendung auf?