SQLserver

Bericht 1 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	07-06-2004
Aan	:	All	MsgID	:	1452.1
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hallo

1) In een query in Access kan ik een dergelijke Alias definieren

Code: [Selecteer]

Adres: [STRAAT] & " " & Format([HUISN];'0000') &
NZ([HUISL];" ") & Format([HUISNTOEV];'0000')
zodat een adres weergegeven wordt als :
  Aakstraat 0002
  Aakstraat 0002a
  Aakstraat 0002 BEDR
  Aakstraat 0002aBEDR

Format zorgt dus voor leading en trailing 0's en NZ()
is een vba NullToZero functie waar het eerste arg het
Truepart en het 2e arg het Falsepart is m.a.w. als er
niets staat (Null) dan een spatie anders de waarde ...

Hoe pruts ik dat in nu precies SQLserver voor elkaar
met als bijkomend gegeven dat HUISN Int(4) is rest varchar

2) een beetje vergelijkbaar is het in Access query's vaakt gebruikte
IIF dus iets als IIf([SRTOBJCODE]>='2000','Ja','Nee') AS Bedrijf
hoe gebruik ik deze in een SQLserver view

3) De indexen werden met importeren vanuit Access niet volledig
goed meegenomen terwijl de data wel conform de eis in de ta-
bellen zit dus geen null of dubbele waardes

Daarom zou ik (ook om meer controle te krijgen) dit liever middels
Stored Procedures sturen en wel een SP met DROP INDEX en CREATE INDEX

Ik heb daarom een SP proc_CreateIndexes_ST geschreven

Code: [Selecteer]

ALTER PROCEDURE dbo.proc_CreateIndexes_ST AS

CREATE UNIQUE INDEX PK ON WOZTABEL20(IID,WNUM)
CREATE INDEX WNUM ON WOZTABEL20(WNUM)
CREATE INDEX STRAAT ON WOZTABEL20(STRAAT)
CREATE INDEX PLAATS ON WOZTABEL20(WNPLTSNAAM)

CREATE UNIQUE INDEX PK ON WOZTABEL21(IID,WNUM)
CREATE INDEX WNUM ON WOZTABEL21(WNUM)
CREATE INDEX GRPAAND ON WOZTABEL21(GRPAAND)

etc

Die de indexes ook maakt alleen ze op e.o.a. manier toch niet uniek maakt
ik denk dat het komt omdat na het maken Allow Nulls nog aangevinkt is,
dus hoe krijg ik die vinkjes via de SP uit

en hoe schrijf ik het als de primairy key index Clustered moet worden
heeft dat trouwens voordelen, de data die wij gebruiken wordt hoofdza-
kelijk per record (1 Woznummer per keer) in een unbound form opgehaald

bvb mijn dank en groetjes -John


Bericht 2 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	07-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.2
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

>> Adres: [STRAAT] & " " & Format([HUISN];'0000') &
NZ([HUISL];" ") & Format([HUISNTOEV];'0000') <<

het NZ Equivalent is COALESCE ?
dus al iets verder gekomen:

Code: [Selecteer]

dbo.WOZTABEL20.STRAAT + ' ' +
CAST(dbo.WOZTABEL20.HUISN AS CHAR(4)) +
COALESCE (dbo.WOZTABEL20.HUISL, ' ') +
COALESCE (dbo.WOZTABEL20.HUISNTOEV, '') AS ADRES
bovendien kwam ik tot de conclusie dat met de default
SET CONCAT_NULL_YIELDS_NULL ON en ergens een Null in
de samenstelling de hele string tot Null evolueert

nu mbt vraag 1 alleen nog de juiste Format '0000'

-- John


Bericht 3 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	Hugo Kornelis	Datum	:	08-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.3
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi John,

> 1) In een query in Access kan ik een dergelijke Alias definieren
>
> Adres: [STRAAT] & " " & Format([HUISN];'0000') &
> NZ([HUISL];" ") & Format([HUISNTOEV];'0000')
>
> zodat een adres weergegeven wordt als :
> Aakstraat 0002
> Aakstraat 0002a
> Aakstraat 0002 BEDR
> Aakstraat 0002aBEDR

Weet je zeker dat je die voorloopnullen wilt? Weet je ook zeker dat er nooit huisnummers groter dan 9999 zullen voorkomen?

En eeuuhh --- wat voor datatype is huisntoev? het gebruik in de format functie wijst in de richting van int, maar de voorbeeld-uitvoer (BEDR) lijkt meer op character gegevens! Voor het onderstaande ga ik ervar uit dat dit een character kolom is en dat je de eerste vier tekens wilt (aangevuld met spaties als de tekst minder dan vier tekens heeft). Tevens neem ik aan dat deze kolom ook NULLS kan bevatten die als blanco getoond moeten worden.

Code: [Selecteer]

SELECT straat + ' ' + RIGHT('0000' + CAST(huisn AS varchar(4)), 4) +
COALESCE(Huisl, ' ') + CAST(COALESCE(Huisntoev, '') AS char(4))

(ongetest - ik hoop dat ik geen haakjes te veel of te weinig heb!)

> Format zorgt dus voor leading en trailing 0's

Hiervoor is geen direct equivalent in SQL Server.

> en NZ()
> is een vba NullToZero functie waar het eerste arg het
> Truepart en het 2e arg het Falsepart is m.a.w. als er
> niets staat (Null) dan een spatie anders de waarde ...

Is equivalent met COALESCE in SQL Server. Je komt ook nog wel eens ISNULL tegen. Dat is een verouderde versie. ISNULL is puut Transact-SQL. COALESCE is gedefinieerd in de ANSI standaard, kan alles wat ISNULL kan en zelfs nog wat meer (meer dan twee argumenten, bijvoorbeeld - het resultaat is het eerste niet-NULL argument in de lijst).

> 2) een beetje vergelijkbaar is het in Access query's vaakt gebruikte
> IIF dus iets als IIf([SRTOBJCODE]>='2000','Ja','Nee') AS Bedrijf
> hoe gebruik ik deze in een SQLserver view

IIF kan meestal worden vervangen door de CASE expressie. Er zijn twee mogelijkheden. Fragment uit Books Online:

Simple CASE function:

Code: [Selecteer]

CASE input_expression
WHEN when_expression THEN result_expression
[ ...n ]
[
ELSE else_result_expression
]
END
Searched CASE function:

Code: [Selecteer]

CASE
WHEN Boolean_expression THEN result_expression
[ ...n ]
[
ELSE else_result_expression
]
END

De door jou gegeven IIf is dus te herschrijven als
CASE WHEN SrtObjCode >= '2000' THEN 'Ja' ELSE 'Nee' END

Met name de tweede versie lijkt veel op IIF, alleen is het aantal WHEN clauses onbeperkt. Denk erom: CASE is een EXPRESSIE, geen control-flow instructie (zoals in veel programmeertalen). Dit levert heel veel verwarring op, maar aangezien jij al bekend bent met IIF zal dat in jouw geval wel meevallen.

> 3) De indexen werden met importeren vanuit Access niet volledig
> goed meegenomen terwijl de data wel conform de eis in de ta-
> bellen zit dus geen null of dubbele waardes
>
> Daarom zou ik (ook om meer controle te krijgen) dit liever middels
> Stored Procedures sturen en wel een SP met DROP INDEX en CREATE INDEX
>
> Ik heb daarom een SP proc_CreateIndexes_ST geschreven
>
> ALTER PROCEDURE dbo.proc_CreateIndexes_ST AS
>
> CREATE UNIQUE INDEX PK ON WOZTABEL20(IID,WNUM)
> CREATE INDEX WNUM ON WOZTABEL20(WNUM)
> CREATE INDEX STRAAT ON WOZTABEL20(STRAAT)
> CREATE INDEX PLAATS ON WOZTABEL20(WNPLTSNAAM)
>
> CREATE UNIQUE INDEX PK ON WOZTABEL21(IID,WNUM)
> CREATE INDEX WNUM ON WOZTABEL21(WNUM)
> CREATE INDEX GRPAAND ON WOZTABEL21(GRPAAND)
>
> etc
>
> Die de indexes ook maakt alleen ze op e.o.a. manier toch niet uniek maakt
> ik denk dat het komt omdat na het maken Allow Nulls nog aangevinkt is,
> dus hoe krijg ik die vinkjes via de SP uit
>
> en hoe schrijf ik het als de primairy key index Clustered moet worden
> heeft dat trouwens voordelen, de data die wij gebruiken wordt hoofdza-
> kelijk per record (1 Woznummer per keer) in een unbound form opgehaald

Ik heb geen ervaring met importeren of met de upsizing wizard. Als ik tabellen maak, dan schrijf ik vrijwel altijd direct de DDL uit. Op die manier kan ik ook een expliciete primary key of UNIQUE constraint definiren. Maar het is inderdaad ook mogelijk om achteraf losse indexen te maken. En een primary key (of UNIQUE constraint) toevoegen kan achteraf ook nog, via ALTER TABLE. Hou er rekening mee dat voor zowel een PK als een UNIQUE door SQL Server altijd een index wordt gemaakt; maak er dus niet zelf een identieke of overlappende index bij. En definieer bij een PK of UNIQUE op meerdere kolommen de kolommen in de "juiste" volgorde.


Wat betreft het afdwingen van uniek-heid: als je een index definieert met het sleutelwoord "UNIQUE", dan wordt dat afgedwongen. Zonder dat sleutelwoord zijn duplicaten gewoon toegestaan (een index is in feite alleen een zoekhulp; een unique index is in feite een verkapte [en niet-standaard] manier om een unique of PK constraint te imiteren). Voor de bepaling van uniek-zijn wordt NULL als een speciale waarde beschouwd. Als je n kolom uniek definieert, dan mag je die kolom bij precies n rij op NULL zetten. Als je een combinatie van twee rijen uniek definieert, dan is bijvoorbeeld "a / NULL" in combinatie met "b / NULL" toegestaan, maar er mag geen tweede "a / NULL" bij komen.


SQL Server definieert als default de index die samenhangt met de primary key als geclusterde index en alle andere indexen ongeclusterd. Je kunt dit veranderen door bij de PK het sleutelwoord "NONCLUSTERED" op te nemen, of bij een index of unique constraint het sleutelwoord "CLUSTERED".


Als je vaak zoekt op een range (komt met name vaak voor bij datum/tijd kolommen: geef alles dat tussen februari en april ...), dan is de kolom waar die range op zoekt vaak een hele goede kandidaat voor de geclusterde index. Als je vaak ORDER BY opneemt met vaak dezelfde kolom(men) dan is/zijn die kolom(men) een goede kandidaat voor de clustered index.


Hou er rekening mee dat je maximaal n clustered index per tabel kunt hebben (en dat het vrijwel altijd onverstandig is om er geen te hebben). De clustered index bepaalt namelijk de volgorde waarin rijen fysiek op de harde schijf worden opgeslagen. Daarom is een clustered index ook zo handig bij zoeken op een range: alles met een xyz-datum tussen maart en april ligt vermoedelijk samen op n of twee datapages, dus de I/O is minimaal.

Een niet geclusterde index is handig bij een groot onderscheidend vermogen. Als je vaak zoekt op gelijkheid en via de index wordt het aantal te bekijken rijen flink teruggebracht grove vuistregel: maximaal 5% mag matchen), dan geeft een non-clustered index winst. De non-clustered index bevat naast de gegevens van de index-kolommen zelf tevens de gegevens van de kolommen in de clustered index. Bij zoeken via een non-clustered index wordt dus altijd daarna ook nog in de clustered index geprikt. (Uitzondering: als de kolommen van de nonclustered index in combinatie met die van de clustered index al volstaan om de query uit te voeren wordt helemaal niet meer verder gezocht, want dan is de rest van de gegevens niet meer nodig. Van dit gegeven kun je soms handig gebruik maken: voeg een schijnbaar nutteloze kolom toe aan een index en een query gaat opeens veel sneller, omdat ALLEEN nog maar in die index hoeft te worden gekeken en niet meer in de tabel zelf. Dit wordt een "covering index" genoemd.


Tenslotte: maak geen indexen op kolommen die je zelden of nooit gebruikt in een WHERE of JOIN (behalve indien nodig om een PK of UNIQUE af te dwingen). Elke index kost overhead bij het wijzigen van de gegevens.

Groetjes, Hugo

Bekijk bericht volledig

Bericht 4 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	Hugo Kornelis	Datum	:	08-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.4
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi John,

> het NZ Equivalent is COALESCE ?
> dus al iets verder gekomen:
>
> dbo.WOZTABEL20.STRAAT + ' ' +
> CAST(dbo.WOZTABEL20.HUISN AS CHAR(4)) +
> COALESCE (dbo.WOZTABEL20.HUISL, ' ') +
> COALESCE (dbo.WOZTABEL20.HUISNTOEV, '') AS ADRES

Zie mijn andere bericht.

> bovendien kwam ik tot de conclusie dat met de default
> SET CONCAT_NULL_YIELDS_NULL ON en ergens een Null in
> de samenstelling de hele string tot Null evolueert

Ja, dat is conform de ANSI standaard. En ook logisch, als je bedenkt dat NULL nog het beste genterpreteerd kan worden als "onbekend". Wat is het resultaat als je iets onbekends concateneerd aan een straatnaam? Juist - dat is onbekend!

I.v.m. backward compatibility heeft SQL Server de mogelijkheid om met de SET optie die jij noemt het oude gedrag m.b.t. concatenatie van NULLS te imiteren. Zo zijn er meer SET opties om oud, niet-standaard gedrag af te dwingen (en de meesten hangen samen met NULL).

Groetjes, Hugo

Bericht 5 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	08-06-2004
Aan	:	Hugo Kornelis	MsgID	:	1452.5
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo

>> bovendien kwam ik tot de conclusie dat met de default
>> SET CONCAT_NULL_YIELDS_NULL ON en ergens een Null in
>> de samenstelling de hele string tot Null evolueert

> Ja, dat is conform de ANSI standaard. En ook logisch, als
> je bedenkt dat NULL nog het beste genterpreteerd kan worden
> als"onbekend". Wat is het resultaat als je iets onbekends
> concateneerd aan een straatnaam? Juist - dat is onbekend!

Enigzins begrijpelijk alleen in Access kan het wel :-)
maar die volgt de ANSI standaard dan ook vaak verre van

> Ivm backward compatibility heeft SQLServer de mogelijkheid
> om met de SET optie die jij noemt het oude gedrag m.b.t.
> concatenatie van NULLS te imiteren. Zo zijn er meer SET
> opties om oud, niet-standaard gedrag af te dwingen
> (en de meesten hangen samen met NULL)

OK ik denk dat ik het beste bij de ANSI standaard blijf

en bedankt weer h !

Groetjes -- John


Bericht 6 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	08-06-2004
Aan	:	Hugo Kornelis	MsgID	:	1452.6
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo

>> Adres: [STRAAT] & " " & Format([HUISN];'0000') &
NZ([HUISL];" ") & Format([HUISNTOEV];'0000')

> Weet je zeker dat je die voorloopnullen wilt?

Ja, das om foto's op Postcode Huisnr te vinden
de foto's hebben een naamgeving volgens deze conventie

> Weet je ook zeker dat er nooit huisnummers
> groter dan 9999 zullen voorkomen?

Ja, het stuf tax bestand laat het niet toe
veldgrootte is max 4 posities

> wat voor datatype is huisntoev?
> Tevens neem ik aan dat deze kolom ook NULLS kan
> bevatten die als blanco getoond moeten worden.

nvarchar en ja er kunnen ook Nulls in voorkomen (meestal)

ps de n staat voor unicode h, is het algemeen gebruikelijk
unicode in SQLserver te gebruiken, het verdubbelt de opslag
en heel veel voordelen zie ik in onze taal niet behalve dat
je wat speciale leestekens kan gebruiken

> SELECT straat + ' ' + RIGHT('0000' + CAST(huisn AS varchar(4)), 4) +
COALESCE(Huisl, ' ') + CAST(COALESCE(Huisntoev, '') AS char(4))

hij werkt precies als gewenst !

ps als je CHAR gebruikt neemt hij dan altijd
4 posities dus bv: AB + 2 spaties?

>> en NZ()

> Is equivalent met COALESCE in SQL Server.
> Je komt ook nog wel eens ISNULL tegen. Dat is een verouderde versie
> COALESCE is gedefinieerd in de ANSI standaard, kan alles wat ISNULL
> kan en zelfs nog wat meer (meer dan twee argumenten, bijvoorbeeld -
> het resultaat is het eerste niet-NULL argument in de lijst).

dat had ik net gevonden ja, alleen is het nu duidelijk welke te nemen


>> IIf([SRTOBJCODE]>='2000','Ja','Nee') AS Bedrijf

> IIF kan meestal worden vervangen door de CASE expressie.
> Er zijn twee mogelijkheden. Fragment uit Books Online:
> De door jou gegeven IIf is dus te herschrijven als
> CASE WHEN SrtObjCode >= '2000' THEN 'Ja' ELSE 'Nee' END

en ook die werkt naar behoren!

op de indexen kom ik nog terug, ik ga nu eerst gebruik maken
van het mooie weer en wat buiten schilderen (vorig jaar een
nieuw huis gebouwd en dat moet nog helemaal afgeschilderd worden)

tot zover weer bedankt voor jou hulp !

Groetjes --John


Bericht 7 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	Hugo Kornelis	Datum	:	09-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.7
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi John,

> ps de n staat voor unicode h,

Yep. De 'n' is een afkorting van 'national' en geeft inderdaad aan dat unicode wordt gebruikt. En dat kost dus twee bytes per teken (i.p.v. n byte per teken zoals bij "gewoon" char, varchar en text).

> is het algemeen gebruikelijk
> unicode in SQLserver te gebruiken, het verdubbelt de opslag
> en heel veel voordelen zie ik in onze taal niet behalve dat
> je wat speciale leestekens kan gebruiken

Ik gebruik het zelf niet, tenzij blijkt dat het nodig is (en dat is tot nu toe nog niet gebeurd). Als je de Latin1-general codepage gebruikt (en die is volgens mij standaard), dan heb je volgens mij alle in Westerse talen gebruikte tekens tot je beschikking. De unicode versie van de velden is met name bedoeld voor slavische, oosterse en andere exotische talen.

> > SELECT straat + ' ' + RIGHT('0000' + CAST(huisn AS varchar(4)), 4) +
> COALESCE(Huisl, ' ') + CAST(COALESCE(Huisntoev, '') AS char(4))
>
> hij werkt precies als gewenst !
>
> ps als je CHAR gebruikt neemt hij dan altijd
> 4 posities dus bv: AB + 2 spaties?

Als je CHAR(4) gebruikt wel. Alleen CHAR geeft (meen ik) een default van CHAR(1). Ik heb in de formule bewust gekozen voor CHAR ipv VARCHAR om die padding te krijgen.

> op de indexen kom ik nog terug, ik ga nu eerst gebruik maken
> van het mooie weer en wat buiten schilderen (vorig jaar een
> nieuw huis gebouwd en dat moet nog helemaal afgeschilderd worden)

Succes met schilderen! Ik ben bang dat ik je dr niet mee kan helpen! :-)

Groetjes, Hugo

Bericht 8 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	11-06-2004
Aan	:	Hugo Kornelis	MsgID	:	1452.8
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo

>> Als ik tabellen maak, dan schrijf
ik vrijwel altijd direct de DDL uit.

in deze applicatie worden de tabellen kant en klaar aangeleverd
en dat weer met een grote regelmaat en voor meerdere gemeentes

dus zit ik hier vrij vaak mee, in Access haal ik de aanwezige
indexen er eerst af en voeg de juisteweer toe, daarvoor heb ik
een routine geschreven, die handig is bij grote bewerkingen om
even tijdelijk bepaalde indexen te verwijderen en terug te zetten

Dus eigenlijk zoek de juiste manier en/of een tooltje dat
1) alle aanwezige indexen in een bestandje plaatst
2) alle indexen (of delen) uit een bestandje terug kan plaatsen

Het kan in elk geval via ADOX en ik heb ook al iets gemaakt in
SQLDMO middels een verwijzing naar de sqldmo.dll en in vb code
maar de laatste alleen om snel de tekst van views en sp's in
een platte tekst file te dumpen

maar het liefst doe ik het rechtstreeks via DDL b.v. in een
Stored Procedure, en om niet opnieuw het wile uit te vinden :-)

>> Hou er rekening mee dat voor zowel een PK als een UNIQUE
door SQLServer altijd een index wordt gemaakt; maak er dus
niet zelf een identieke of overlappende index bij.

Is dat net als in Access een verborgen index (maw niet direkt
in de ui zichtbaar?) maar als je een compound index hebt - en
ook veel op een aparte kolom van die index veel bewerkingen
uitvoert- moet je toch wel een aparte index er bij zetten?

Groetjes --John


Bericht 9 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	11-06-2004
Aan	:	Hugo Kornelis	MsgID	:	1452.9
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo

Mbt de indexen loop ik toch nog tegen een probleem aan

In het protoype in Access werkt alles prima alleen is
SQL server wat eigenzinnig met indexen en pk's :-)
-------------------------------------------------------

In vrijwel alle tabellen is WOZnummer een uniek gegeven
echter van dit WOZnummer kunnen meerdere tijdvakken zijn
dus is daarnaast een ID als tijdvak identifier toegevoegd

Samen vormen WOZnummer + ID dus een compound Primairy key

Dit werkt bij navigeren etc overal prima de tabellen zijn
ook updatable, alleen bij inserts loop ik tegen problemen

Ik heb van enkele tabellen alle indexen gedelete en daarna
voor elke tabel deze nieuwe compound primairy key aangemaakt

Als ik een *unieke* rij in wil voegen dan volgt er een fout:

'Schending van Primairy key beperking PK_WOZTABEL20.
Kan geen dubbelle sleutel invoegen in object WOZTABEL20'

Er is dus maar 1 index met de naam: PK_WOZTABEL20
volgorde is goed : WNUM ID

ps
1) heeft het zin deze compound index Clustered te maken
2) als er regerlmatig apart op WNUM of ID gewerkt wordt heeft
het dan zin extra aparte indexen op deze kolmmen te plaatsen

Groetjes --John


Bericht 10 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	11-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.10
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo,

>> Dus eigenlijk zoek de juiste manier en/of een tooltje dat

Ik zie net dat er in de enterprise manager een script tool zit
hieronder het vandaaruit gegenereerde script van de eerste 3
tabellen die dus geen inserts accepteren ondanks uniqueness
op WNUM + IID

Code: [Selecteer]

ALTER TABLE [dbo].[WOZTABEL20] WITH NOCHECK ADD
CONSTRAINT [PK_WOZTABEL20] PRIMARY KEY CLUSTERED
(
[WNUM],
[IID]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[WOZTABEL21] WITH NOCHECK ADD
CONSTRAINT [PK_WOZTABEL21] PRIMARY KEY CLUSTERED
(
[WNUM],
[IID]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[WOZTABEL22] WITH NOCHECK ADD
CONSTRAINT [PK_WOZTABEL22] PRIMARY KEY CLUSTERED
(
[WNUM],
[IID],
[NUMODEEL],
[GEHWRDERINGSVSCHR]
) ON [PRIMARY]
GO
Groetjes --John


Bericht 11 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	12-06-2004
Aan	:	Hugo Kornelis	MsgID	:	1452.11
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo,

Nog vergeten te melden:
handmatige invoer (insert) werkt wel maar zodra het middels
onderstaande of in ADO gebeurt volgt de voormelde fout ...

voor de volledigheid hieronder n van de stored procedures

Code: [Selecteer]

ALTER PROCEDURE dbo.proc_appWOZTABEL21

(@WNUM float,@IID int)

AS INSERT INTO dbo.WOZTABEL21
(MUTBEGIN, MUTEINDE, WNUM, IID, WIJKCODE, BUURTCODE,
WAARDEOZBELAST, REDENVERSCH, GETAXWAARDE, GHANTEERDWVOORSCHR,
MONAAND, CODEOMZETBEL, GRPAAND, TYPEAAND, SRTOBJCODE, LIFT,
LIGGING, NUTSVZ, FINVORM, FOTINDN, AANT, TAXDAT, TAXATEUR,
INPOPN, STIJLL, PERCGEREED, MUTCODE, INGDAT, EINDDAT)

SELECT MUTBEGIN, MUTEINDE, @WNUM AS W, @IID AS I, WIJKCODE, BUURTCODE,
WAARDEOZBELAST, REDENVERSCH, GETAXWAARDE, GHANTEERDWVOORSCHR,
MONAAND, CODEOMZETBEL, GRPAAND, TYPEAAND, SRTOBJCODE, LIFT,
LIGGING, NUTSVZ, FINVORM, FOTINDN, AANT, TAXDAT, TAXATEUR,
INPOPN, STIJLL, PERCGEREED, MUTCODE, INGDAT, EINDDAT
FROM dbo.WOZTABEL21

ook als ik hardcoded waardes invul ipv de parameterwaardes
krijg ik dezelfde foutmelding alleen niet indien handmatig

Groetjes --John


Bericht 12 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	12-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.12
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo,

Inmiddels opgelost: fout in WHERE voorwaarde (ontbrekende parameter)
waardoor hij alle records met dit WOZnr wou inserten en dus ook dup's

Code: [Selecteer]

ALTER PROCEDURE dbo.proc_appWOZTABEL21
(@WNUM float,@IID int)

AS
SET NOCOUNT ON

INSERT INTO dbo.WOZTABEL21
(MUTBEGIN, MUTEINDE, WNUM, IID, WIJKCODE, BUURTCODE, WAARDEOZBELAST,
REDENVERSCH, GETAXWAARDE, GHANTEERDWVOORSCHR, MONAAND, CODEOMZETBEL,
GRPAAND, TYPEAAND, SRTOBJCODE, LIFT, LIGGING, NUTSVZ, FINVORM, FOTINDN,
AANT, TAXDAT, TAXATEUR, INPOPN, STIJLL, PERCGEREED, MUTCODE, INGDAT, EINDDAT)

SELECT MUTBEGIN, MUTEINDE, WNUM, @IID AS I, WIJKCODE, BUURTCODE, WAARDEOZBELAST,
REDENVERSCH, GETAXWAARDE, GHANTEERDWVOORSCHR, MONAAND, CODEOMZETBEL, GRPAAND,
TYPEAAND, SRTOBJCODE, LIFT, LIGGING, NUTSVZ, FINVORM, FOTINDN, AANT, TAXDAT,
TAXATEUR, INPOPN, STIJLL, PERCGEREED, MUTCODE, INGDAT, EINDDAT

FROM dbo.WOZTABEL21

WHERE (WNUM = @WNUM) AND (IID = 1)
ik moet 3 x 1 record uit verschillende tabellen in n run aan de database toevoegen
dus bovenstaande (met verschillende veldnamen uiteraard) 3 x achter elkaar uitvoeren
nu run ik 3 procedures na elkaar, maar dat kan natuurlijk ook in 1 procedure met een
transactie (input parameters zijn voor alle 3 hetzelfde) kan je eens een voorbeeldje
raamwerk geven gebasserd op bovenstaande svp ?

Groetjes --John


Bericht 13 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	Hugo Kornelis	Datum	:	12-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.13
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi John,

> >> Als ik tabellen maak, dan schrijf
> ik vrijwel altijd direct de DDL uit.
>
> in deze applicatie worden de tabellen kant en klaar aangeleverd
> en dat weer met een grote regelmaat en voor meerdere gemeentes
>
> dus zit ik hier vrij vaak mee, in Access haal ik de aanwezige
> indexen er eerst af en voeg de juisteweer toe, daarvoor heb ik
> een routine geschreven, die handig is bij grote bewerkingen om
> even tijdelijk bepaalde indexen te verwijderen en terug te zetten

Ik neem aan dat je de INHOUD van de tabellen kant en klaar krijgt aangeleverd en dat je die dan kopieert naar SQL Server. Je zult dan toch eerst de tabel (of tabellen) in SQL Server moeten aanmaken waar die inhoud in kan. Als je die tabel eenmaal hebt, dan kun je vervoglens op verschillende manieren de gegevens vanuit een externe bron in die tabel krijgen.

> Dus eigenlijk zoek de juiste manier en/of een tooltje dat
> 1) alle aanwezige indexen in een bestandje plaatst
> 2) alle indexen (of delen) uit een bestandje terug kan plaatsen

Je hebt zelf (zag ik in een ander berichtje) al ontdekt dat je via Enterprise Manager scripts kunt maken. Die kun je bewaren en later weer uitvoeren (via Query Analyzer, maar ook via bv osql) om de betreffende constraints opnieuw te maken. Ditzelfde kun je overigens ook doen voor tabellen, triggers, procedures, etc.

Je kunt de INFORMATION_SCHEMA views gebruiken om zelf script te maken voor het verwijderen van elementen. Het volgende bijvoorbeeld genereert een script voor het verwijderen van alle primary key constraints en alle unique constraints:

Code: [Selecteer]

SELECT 'alter table ' + TABLE_NAME + ' drop constraint '
+ CONSTRAINT_NAME + CHAR(10) + 'go'
FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
WHERE CONSTRAINT_TYPE IN ('PRIMARY KEY', 'UNIQUE')
(uitvoeren in Query Analyzer met output in text mode - het resultaat kun je vanuit het resutlaat venster knippen en plakken in het query venster om direct uit te voeren, of knippen en plakken in een bestandje voor later.)

> maar het liefst doe ik het rechtstreeks via DDL b.v. in een
> Stored Procedure, en om niet opnieuw het wile uit te vinden :-)

Voor taken die je alleen zelf uitvoert zou ik een los bestandje met SQL opdrachten op je eigen systeem bewaren. Als lokale beheerders het moeten kunnen uitvoeren, dan is een stored procedure de aangewezen manier.

> >> Hou er rekening mee dat voor zowel een PK als een UNIQUE
> door SQLServer altijd een index wordt gemaakt; maak er dus
> niet zelf een identieke of overlappende index bij.
>
> Is dat net als in Access een verborgen index (maw niet direkt
> in de ui zichtbaar?) maar als je een compound index hebt - en
> ook veel op een aparte kolom van die index veel bewerkingen
> uitvoert- moet je toch wel een aparte index er bij zetten?

Nee, de index die wordt gegenereerd om een Primary key of Unique constraint te kunnen controleren is precies net zo zichtbaar als een index die je zelf maakt. Ik raad je aan het CREATE INDEX commando alleen te gebruiken voor het maken van niet unieke indexen; als iets uniek moet zijn is een Unique constraint de logischere keuze.

Het enige verschil tussen de index die je met CREATE INDEX maakt en de index die SQL Server zelf maakt als je een PK of UNIQUE opgeeft, is dat je bij een CREATE INDEX altijd een naam moet opgeven; bij PK/UNIQUE is dat niet verplicht (dan genereert SQL Server zelf een naam).

Groetjes, Hugo

Bericht 14 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	Hugo Kornelis	Datum	:	12-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.14
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi John,

> Mbt de indexen loop ik toch nog tegen een probleem aan
(...)
> Als ik een *unieke* rij in wil voegen dan volgt er een fout:
>
> 'Schending van Primairy key beperking PK_WOZTABEL20.
> Kan geen dubbelle sleutel invoegen in object WOZTABEL20'
>
> Er is dus maar 1 index met de naam: PK_WOZTABEL20

Ik heb inmiddels in een ander bericht gelezen dat je dit hebt opgelost. Of ging dat ergens anders over?

> volgorde is goed : WNUM ID

Voor de controle op uniekheid maakt de volgorde niet uit. De volgorde is alleen van belang voor het al dan niet bruikbaar zijn van de index die bij de PK wordt gegenereerd. (Kom ik straks op terug)

> 1) heeft het zin deze compound index Clustered te maken

Op deze vraag is maar n antwoord mogelijk: "it depends".

Ik kan je wel een paar vuistregels geven:

1. Als een tabel maar n index heeft, dan is het in 99% van de gevallen aan te raden om die te clusteren.

2. Een clustered index kan snelheidswinst geven als in een query moet worden gezocht op kleiner of groter dan, op een bereik (BETWEEN) of als de kolom (of kolommen) van die index in een ORDER BY gebruikt worden.

3. Een niet geclusterde index zal door de optimizer alleen gebruikt worden als de optimizer een hoge selectiviteit verwacht. Het omslagpunt hangt van een boel factoren af, maar vaak ligt het zo rond de 5%. Alleen als de optimizer verwacht dat meer dan 95% van de rijen niet benaderd hoeft te worden als op de index wordt gezocht zal de index gebruikt worden, anders wordt veelal de voorkeur gegeven aan een table scan.

In de praktijk zie je heel vaak dat er op een kolom met zoiets als datum geldigheid of ingangsdatum een niet unieke geclusterde index wordt gelegd, omdat dit soort datums vaak worden gebruikt met kleiner dan, groter dan of BETWEEN bepaalde datums. De primaire sleutel wordt in veel queries gebruikt in de vorm van kolomnaam = waarde; omdat er voor de PK per definitie maar n rij kan voldoen aan die voorwaarde is de selectiviteit bijzonder hoog, zodat ook een niet geclusterde index in dit geval efficint is.

> 2) als er regerlmatig apart op WNUM of ID gewerkt wordt heeft
> het dan zin extra aparte indexen op deze kolmmen te plaatsen

Als je de PK hebt opgegeven op (WNUM, ID), dan heeft een extra index op alleen WNUM geen zin; een extra index op alleen ID (of op ID in combinatie met n of meer andere kolommen) kan wel zin hebben. Als je vaak met alleen ID gewerkt wordt en zelden met alleen WNUM, dan kun je de definitie van de PK beter vervangen door (ID, WNUM) [de volgorde omdraaien, dus].

Analogie: zoeken in het telefoonboek van Amsterdam. De vermeldingen staan alfabetisch op achternaam; mensen met dezelfde achternaam zijn gesorteerd op straatnaam. Deze fysieke volgorde van het telefoonboek is dus in feite de geclusterde index. Zoek je het nummer van Jansen aan de Lindenlaan, dan blader je snel naar de pagina waar de eerste Jansen staat, racet door de kolommen naar de L vna Lindenlaan en je hebt hem/haar direct. Zoek je een Jansen van wie je bijvoorbeeld wel het beroep weet, maar niet het adres, dan hoef je nog steeds niet het hele boek door; je moet wel alle Jansens bekijken. Maar als je op zoek bent naar het nummer van Lindenlaan 37a, dan heb je pech - want er is in het telefoonboek geen index opgenomen op straatnaam.....

Met de bruikbaarheid van indexen voor SQL Server werkt het net zo. Een index op kolommen a-b-c kan gebruikt worden voor selectie op basis van a-b-c, a-b of alleen a, maar niet voor selectie op basis van b-c, alleen b of alleen c. En bij selectie op a-c wordt de index gebruikt voor selectie op a, waarna de selectie op c plaatsvindt voor alle rijen die op basis van de juiste a geselecteerd waren.

Groetjes, Hugo

Bericht 15 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	Hugo Kornelis	Datum	:	12-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.15
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi John,

> ik moet 3 x 1 record uit verschillende tabellen in n run aan de database
> toevoegen dus bovenstaande (met verschillende veldnamen uiteraard) 3 x
> achter elkaar uitvoeren nu run ik 3 procedures na elkaar, maar dat kan
> natuurlijk ook in 1 procedure met een transactie (input parameters zijn
> voor alle 3 hetzelfde) kan je eens een voorbeeldje raamwerk geven
> gebasserd op bovenstaande svp ?

Zoiets als dit, wellicht?

Code: [Selecteer]

CREATE PROCEDURE dbo.DrieInserts (argumentenlijst)
AS
DECLARE @Foutje varchar(3)
SET @Foutje = 'nee'
SET NOCOUNT ON
BEGIN TRANSACTION

INSERT INTO dbo.Tabel1 (kolomlijst)
SELECT kolomlijst
FROM dbo.BronTabel1
WHERE voorwaarden
IF @@ERROR <> 0
SET @Foutje = 'Ja'

INSERT INTO dbo.Tabel2 (kolomlijst)
SELECT kolomlijst
FROM dbo.BronTabel2
WHERE voorwaarden
IFD @@ERROR <> 0
SET @Foutje = 'Ja'

INSERT INTO dbo.Tabel3 (kolomlijst)
SELECT kolomlijst
FROM dbo.BronTabel3
WHERE voorwaarden
IF @@ERROR <> 0
SET @Foutje = 'Ja'

IF @Foutje = 'Ja'
BEGIN
RAISERROR ('Het is mislukt!', 16, 1)
ROLLBACK TRANSACTION
END
ELSE
COMMIT TRANSACTION
END
go
Uiteraard verdient de foutafhandeling in dit voorbeeld geen schoonheidsprijs, maar dat kun je ongetwijfeld zelf nog verbeteren.

Groetjes, Hugo

PS: Ik hoop dat ik nu alle openstaande vragen heb beantwoord. Ben ik toch nog iets vergeten, trek me dan svp nog even aan mijn viotuele jasje!

Bericht 16 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	13-06-2004
Aan	:	Hugo Kornelis	MsgID	:	1452.16
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo

> Ik neem aan dat je de INHOUD van de tabellen kant en klaar
> krijgt aangeleverd en dat je die dan kopieert naar SQLServer

Ik krijg een uit AS400 ? gegenereerd txt bestand aangeleverd
dit gaat door een converter die alles in stuuken hakt en in
Access tabellen gooit, deze Access tabellen heb ik 1 ker via
de upsize wizard en 1x via DTS geimporteerd in SQL server,
dus niet eerst tabellen gemaakt en deze gevuld ...

> Je hebt zelf (zag ik in een ander berichtje) al ontdekt dat
> je via Enterprise Manager scripts kunt maken. Die kun je
> bewaren en later weer uitvoeren (via Query Analyzer, maar
> ook via bv osql) om betreffende constraints opnieuw te maken

(luxe) nadeel hier is dat ik in een adp (Access Data Project)
werk en dus niet 'veroordeelt' ben tot SQL server tools alleen
vanuit de ADP kan je ook bijna alles doen, zelfs tabellen impor
teren die dan rechtstreeks en geconverteerd in SQLserver staan

bovendien doe ik een deel in ADO en grijp wel eens naar VB code
dus soms mis je de meest logische oplossing daardoor

> Je kunt de INFORMATION_SCHEMA views gebruiken om zelf script
> te maken voor het verwijderen van elementen. Het volgende bij-
> voorbeeld genereert een script voor het verwijderen van alle
> primary key constraints en alle unique constraints:

> SELECT 'alter table ' + TABLE_NAME + ' drop constraint '
> + CONSTRAINT_NAME + CHAR(10) + 'go'
> FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
> WHERE CONSTRAINT_TYPE IN ('PRIMARY KEY', 'UNIQUE')

> (uitvoeren in Query Analyzer met output in text mode -
> het resultaat kun je vanuit het resutlaat venster knippen
> en plakken in het query venster om direct uit te voeren,
> of knippen en plakken in een bestandje voor later.)

die kende ik nog niet (INFORMATION_SCHEMA) f opgezocht in BOL
en erg handig zal ik zeker gebruik van gaan maken !

alles hier is nu duidelijk, bedankt !

Groetjes --John


Bericht 17 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	13-06-2004
Aan	:	Hugo Kornelis	MsgID	:	1452.17
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo,

>> Mbt de indexen loop ik toch nog tegen probleem

> Ik heb inmiddels in een ander bericht gelezen dat
> je dit hebt opgelost. Of ging dat ergens anders over?

nee opgelost, stomme fout hier, teveel knippen en
plakken zonder op de werkelijke werking te letten
+ erg veel nieuwigheden (indrukken) en tijdsdruk

>> heeft het zin deze compound index Clustered te maken

> Ik kan je wel een paar vuistregels geven:

heel duidelijk, geen verdere vragen hierover !

>> als er regelmatig apart op WNUM of ID gewerkt wordt heeft
>> het dan zin extra aparte indexen op deze kolmmen te plaatsen

> Als je de PK hebt opgegeven op (WNUM, ID), dan heeft een extra
> index op alleen WNUM geen zin; een extra index op alleen ID
> (of op ID in combinatie met n of meer andere kolommen) kan
> wel zin hebben. Als je vaak met alleen ID gewerkt wordt en
> zelden met alleen WNUM, dan kun je de definitie van de PK
> beter vervangen door (ID, WNUM) [de volgorde omdraaien, dus]

Vrijwel altijd wordt er gezocht in de volgorde en het meest nog
op WNUM, joins worden vrijwel altijd op beide gelegd, ID in een
combinatie met ander veld wordt vrijwel niet gebruikt, dus lijkt
het mij voor deze tabel (20) afdoende

alleen nog een index op het veld Straat (of beter op Adres
combinatie Straat-Nr-Lt-Tv) als ik die laatste maak dan lijkt
het haast dat deze beter de (Unieke) Clustered index kan zijn

> Een index op kolommen a-b-c kan gebruikt worden voor selectie op
> basis van a-b-c, a-b of alleen a, maar niet voor selectie op basis
> van b-c, alleen b of alleen c. En bij selectie op a-c wordt de
> index gebruikt voor selectie op a, waarna de selectie op c plaats
> vindt voor alle rijen die op basis van de juiste a geselecteerd waren.

ook duidelijk uitgelegd, wederom bedankt!

Groetjes --John


Bericht 18 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	13-06-2004
Aan	:	Hugo Kornelis	MsgID	:	1452.18
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo,

>> nu run ik 3 procedures na elkaar, maar dat kan
>> natuurlijk ook in 1 procedure met een transactie

> Zoiets als dit, wellicht?

Mooi en werkt prima bedankt weer !

alleen moest ik de laatste END weghalen
(error daarop) laatste regels zijn nu :

Code: [Selecteer]

IF @Foutje = 'Ja'
BEGIN
RAISERROR ('Het is mislukt!', 16, 1)
ROLLBACK TRANSACTION
END
ELSE
COMMIT TRANSACTION
GO
> Uiteraard verdient de foutafhandeling in dit voorbeeld
> geen schoonheidsprijs, maar kun je zelf nog verbeteren

nadeel in ADP is dat je de reurnwaarde niet kan afvangen
bij overgang naar webbased zitten we in VB.net recht op
SQL server dus dan wel

> Ik hoop dat ik nu alle openstaande vragen heb beantwoord

alles is naar volle tevredenheid beantwoord !

't was wat rommelig (alle vragen na en door elkaar) maar dat
kwam dus door tijdsdruk en bovendien is het een mooie manier
om eea van me af te kletsen, zit hier maar alleen te ploeteren
zonder feedback, dit werkt dus ook therapeutisch ;-)

Ik zal ongetwijfeld (spoedig) terug komen met andere vragen
maar dan in een schoon nieuw draadje :-)

Groetjes --John


Bericht 19 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	Hugo Kornelis	Datum	:	13-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.19
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi John,

> Ik krijg een uit AS400 ? gegenereerd txt bestand aangeleverd
> dit gaat door een converter die alles in stuuken hakt en in
> Access tabellen gooit, deze Access tabellen heb ik 1 ker via
> de upsize wizard en 1x via DTS geimporteerd in SQL server,
> dus niet eerst tabellen gemaakt en deze gevuld ...

Ok. In elk geval kun je dan de scripts van EM gebruiken om daarna de constraints en eventuele extra indexen te herstellen.

Groetjes, Hugo

Bericht 20 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	Hugo Kornelis	Datum	:	13-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.20
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi John,

> Vrijwel altijd wordt er gezocht in de volgorde en het meest nog
> op WNUM, joins worden vrijwel altijd op beide gelegd, ID in een
> combinatie met ander veld wordt vrijwel niet gebruikt, dus lijkt
> het mij voor deze tabel (20) afdoende
>
> alleen nog een index op het veld Straat (of beter op Adres
> combinatie Straat-Nr-Lt-Tv) als ik die laatste maak dan lijkt
> het haast dat deze beter de (Unieke) Clustered index kan zijn

Met name als er vaak een lijst van alle objecten in een straat gevraagd wordt zou je hier heel goed gelijk in kunnen hebben. Maar om het zeker te weten is de beste methode: testen. Probeer gewoon alle varianten die je overweegt, vul de tabellen met een representatieve set gegevens en meet de performance van een paar typische queries.

In Query Analyser kun je via een menukeuze een grafische weergave krijgen van het execution plan. Verder kun je met diverse SET opties informatie krijgen over de gebruikte I/O en CPU-tijd. Zie Books Online, onderdelen SET STATISTICS IO en SET STATISTICS TIME.

Groetjes, Hugo

Bericht 21 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	Hugo Kornelis	Datum	:	13-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.21
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi John,

> > Zoiets als dit, wellicht?
>
> Mooi en werkt prima bedankt weer !
>
> alleen moest ik de laatste END weghalen

Ja, foutje van mij. En ik zie nu ook dat ik n keer IFD in plaats van IF heb ingetypt.

> nadeel in ADP is dat je de reurnwaarde niet kan afvangen

Hmmm, ik ken ADP niet. Kijk eens in Books Online bij de T-SQL opdracht RETURN. Daar kun je een returnwaarde mee teruggeven aan de aanroepende client; wellicht dat ADP die netjes in ontvangst neemt?

> zit hier maar alleen te ploeteren
> zonder feedback, dit werkt dus ook therapeutisch ;-)

Normaal zou je in elk geval van mij veel sneller feedback hebben gekregen, maar we hebben een krankzinnige week achter de rug (in n week de crematie van mijn oma, de verhuizing van mijn schoonmoeder van een verzorgingshuis naar een verpleeghuis en de ontruiming van haar kamer in het verzorgingshuis, dus ik was op het laatst compleet gevloerd).

> Ik zal ongetwijfeld (spoedig) terug komen met andere vragen
> maar dan in een schoon nieuw draadje :-)

Prima - ik zit er klaar voor om je vragen te beantwoorden.

Groetjes, Hugo

Bericht 22 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	17-06-2004
Aan	:	Hugo Kornelis	MsgID	:	1452.22
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo,

>> In Query Analyser kun je via een menukeuze een grafische weergave
krijgen van het execution plan. Verder kun je met diverse SET
opties informatie krijgen over de gebruikte I/O en CPU-tijd.
Zie Books Online, onderdelen SET STATISTICS IO en SET STATISTICS TIME

ok bedankt voor deze tip, als er wat meer tijd is zal ik de indexen
eens kritisch bekijken en op een redelijk gevulde database testen

groetjes -- John


Bericht 23 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	John Kopmels (Sysop)	Datum	:	17-06-2004
Aan	:	Hugo Kornelis	MsgID	:	1452.23
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi Hugo,

>> nadeel in ADP is dat je de returnwaarde niet kan afvangen

> ik ken ADP niet. Kijk eens in Books Online bij de T-SQL opdracht
RETURN. Daar kun je een returnwaarde mee teruggeven aan de aan
roepende client; wellicht dat ADP die netjes in ontvangst neemt?

Ik citeer uit 'Microsoft Access Projects and Microsoft SQL Server'

Return values cannot be evaluated in the Access user interface.
You can only access the return value by calling the stored procedure
from another stored procedure or from a program utilizing ADO
or smilar components.

wederom bedankt voor jou tijd en groetjes --John


Bericht 24 van 24

NL Computer Forum ~ SQL & Programmeren

Van	:	Hugo Kornelis	Datum	:	18-06-2004
Aan	:	John Kopmels (Sysop)	MsgID	:	1452.24
Onderwerp	:	SQLserver	Forum	:	ws-nlcomputer

Hoi John,

> wederom bedankt voor jou tijd en groetjes

Als altijd, graag gedaan!

Groetjes, Hugo