[MSSQL] St.Proc. resume on error?

[Altaphista]

Is het mogelijk dat een SP na een error gewoon verder gaat en de error niet weergeeft? (dit ivm performance). Op dit moment insert ik waarden in een tabel en soms komt de combinatie al voor. Maar om eerst te gaan checken of de combinatie al bestaat kost ontzetten veel tijd (enkele ms, en dat keer een paar miljoen) en daarom wil ik gewoon inserten. (ik heb al getest: uiteindelijke voordeel = 2 uur op 2 1/4 uur... dus het kan wel uit ) Ik wil alleen die 'duplicate key'-error niet telkens hebben...

[faabman]

de eigenschappen van het betreffende tabel-veld aanpassen zodat duplicaten wel zijn toegestaan

hier staat misschien een antwoord op je vraag
http://65.61.175.198/t892679.html

[google=ignore error sqlserver]

[Altaphista]

FvKnijff schreef op 20 oktober 2003 @ 13:48:
de eigenschappen van het betreffende tabel-veld aanpassen zodat duplicaten wel zijn toegestaan

hier staat misschien een antwoord op je vraag
http://65.61.175.198/t892679.html

[google=ignore error sqlserver]

ok, zoiets moet ik hebben, maar ik kan geen optie 'ticken' (aanvinken) dat ie de duplicates moet ignoren zoals bij het importeren van een csv ...
En waarom heb ik het niet aan staan? Omdat ik geen duplicates moet hebben.

[faabman]

oww, dus je wilt dat de combinaties die bestaan gewoon niet worden ingevoerd??

weet niet zeker of het in sqlserver kan, maar, in vbscript kan een on error resume next

en misschien kan je met transactions het een en ander uitvogelen

[SuperRembo]

Vertel wat meer over wat je aan het doen bent, waar komt de data vandaan, hoe voer je die tsql uit. En wat bedoel je met "Ik wil alleen die 'duplicate key'-error niet telkens hebben", een tsql script gaat namelijk gewoon verder bij zo'n error tenzij je zelf actie onderneemt.

[Altaphista]

SuperRembo schreef op 20 October 2003 @ 14:08:
Vertel wat meer over wat je aan het doen bent, waar komt de data vandaan, hoe voer je die tsql uit. En wat bedoel je met "Ik wil alleen die 'duplicate key'-error niet telkens hebben", een tsql script gaat namelijk gewoon verder bij zo'n error tenzij je zelf actie onderneemt.

OK:
1. select 1 milj (soms meer) records uit een temp tabel (met outer join, dus if exist) into cursor
2. (was:) check in nieuwe tabel IF exist (met een SELECT), maar dit kost teveel tijd
3. insert into nieuwe tabel(PK_1, PK_2). Een soort koppeltabel.

je begrijpt dat mét stap 2 erbij het echt veel tijd kost, dus heb ik die eruit gelaten. Maar stap 3 geeft 1 op de zoveel keer een DUPL key terug, en dat wil ik niet.

[ Voor 3% gewijzigd door Altaphista op 20-10-2003 14:41 . Reden: typo ]

[SuperRembo]

Kan je in die query niet voor elkaar krijgen dat ze uniek zijn?

[P_de_B]

Volgens mij kun je beter een BULK INSERT gebruiken, hierbij kun je aangeven of constraints gecontroleerd moeten worden.

Check Books Online maar eens voor BULK INSERT

[Annie]

Kan je niet gebruik maken van een

SQL:

INSERT INTO tabel (kolom) SELECT bla FROM temptabel WHERE foo = bar

constructie? De select query kan je dan helemaal volgens je eigen voorwaarden samenstellen.
Werken met Cursors is in 9 van de 10 gevallen sowieso vragen om performance problemen.

[ Voor 16% gewijzigd door Annie op 20-10-2003 19:06 ]

[farlane]

Kun je die eerste query niet zo formuleren dattie meteen alleen de records pakt die nog niet in de tabel staan ?

[Altaphista]

SuperRembo schreef op 20 October 2003 @ 15:05:
Kan je in die query niet voor elkaar krijgen dat ze uniek zijn?

ja, maar dan moet ik eerst een select uitvoeren, wat weer enorm veel tijd kost.

P_de_B schreef op 20 October 2003 @ 15:12:
Volgens mij kun je beter een BULK INSERT gebruiken, hierbij kun je aangeven of constraints gecontroleerd moeten worden.

Check Books Online maar eens voor BULK INSERT

OK, dit heb ik bekeken, ziet er goed uit. Nu nog ff wat vinden over "IGNORE_DUP_ROW". Ik had al wel wat gevonden voor een INDEX maar dat is ook weer zo'n 'omweg'

SQL:

CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name 
    ON { table | view } ( column [ ASC | DESC ] [ ,...n ] ) 
[ WITH < index_option > [ ,...n] ] 
[ ON filegroup ]

< index_option > :: = 
    { PAD_INDEX | 
        FILLFACTOR = fillfactor | 
        IGNORE_DUP_KEY | 
        DROP_EXISTING | 
    STATISTICS_NORECOMPUTE | 
    SORT_IN_TEMPDB  
}

Annie, werken met de cursor was in dit geval echt het handigst ik weet dat het trager is, temptabel etc is sneller...

farlane schreef op 20 October 2003 @ 20:04:
Kun je die eerste query niet zo formuleren dattie meteen alleen de records pakt die nog niet in de tabel staan ?

nee, dan moet je dus eerst een (trage) select uitvoeren om daar achter te komen...