[sql 2000 stored procedure] string parameters

[joopst]

In de app die ik maak voor mijn werk maken we gebruik van een sql 2000 database. Via stored procedures lezen en updaten de data.
Nu heb ik een probleem gehad met de lengte van een nvarchar parameter. Op dit forum, op internet in de msdn kon ik niks vinden na een half uur zoeken, dus verblijd ik jullie met mij vraagje

Ik zal eens beginnen met de situatie uit te leggen. Dan is duidelijk waar het over gaat.

situatie: een stored procedure

code:

create procedure testclip
@Param AS NVARCHAR(10)
AS 
select  @Param

als ik die aanroep met in de parameter een string langer dan 10, dan wordt deze afgekapt.
de aanroep:

code:

testclip '123456789012345678901'

het resultaat:

code:

1234567890

De parameters van de sp's zijn strong typed en hebben een lengte van 10.

ik wil eigenlijk dat ipv dat de string wordt afgekapt, er een exception optreedt. Anders kan je zomaar zonder dat je het weet dataverlies krijgen.
Weet iemand wat ik verkeerd doe? of waar ik dat in kan stellen ?

alvast bedankt!

[kenneth]

Checken voordat je de SP aanroept.
Hoe ziet de aanroepende code eruit?

[joopst]

Voor het aanroepen maak ik gebruik van de ms entlib

Uiteraard kan ik het ook checken voordat ik de database benader, maar ik vind het zo raar dat ik in de stored procedure een lengte opgeef van de parameter en dat als ik iets langers erin stop, er gewoon automatisch zonder iets te zeggen een stuk van mijn string wordt afgeknipt.

Ik vind dat de database een exception moet gooien als dit gebeurt.

En natuurlijk kan ik dan in mijn code weer checken op lengte, UI aanpassen, gebruiker vragen, weet ik wat, maar in ieder geval is het niet handig dat zomaar wat data verloren gaat zonder dat je het weet.

En het liefste houd ik de verantwoordelijkheid voor het checken van database-parameter- en database-kolomlengten in de database, want mocht er iets veranderen, dan hoef ik mijn app niet aan te passen.

[Lethalis]

CHECK constraint gebruiken die op de lengte checkt.

[kenneth]

Een exceptie is een uitzondering. Je moet je gegevens gewoon controleren voordat je ze meegeeft aan de SP. Niet zomaar wat user input erheen gooien en maar zien waar het schip strandt.
En als ik me niet vergis, is het truncaten van een varchar gewoon beschreven gedrag.

@Lethalis: CHECK constraint op een SP

[ Voor 8% gewijzigd door kenneth op 31-01-2006 13:19 ]

[RobIII]

Je kunt toch de .Parameters collectie van een Command uitlezen en zo bepalen of een bepaalde waarde te lang is? Verander je je SP dan hoef je je app dus niet aan te passen.

* Disclaimer: Even uit de blote bol.

[Lethalis]

kenneth schreef op dinsdag 31 januari 2006 @ 13:18:
@Lethalis: CHECK constraint op een SP

Dat kan inderdaad niet.. sorry

Ik las het weer niet goed..

[cannibal]

dat ie geen foutmelding geeft zou ook wel eens kunnen liggen aan het feit dat je een (n)varchar gebruikt en geen char.

Je zou eens een testje moeten doen met een char waarde.
Meen me te herinneren dat wij vroeger ook foutmeldingen kregen als we een te lange string waarde wilde opslaan.

Het verschil kan 'm natuurlijk ook liggen aan het feit dat wij niet met sp's werken, maar met sql-strings (soms geparameteriseerd) ipv met sp's. Zou dus ook kunnen dat het probleem al bij het aanroepen van de sp ligt en niet bij het uitvoeren van de uiteindelijke insert/update query.

[joopst]

ik kan het ook wel oplossen, maar ik vind het gewoon vaag dat je in de database niet kan instellen dat je een melding krijgt als de database je data gaat weggooien.
schijnbaar is dat heel normaal dat de db zonder iets te zeggen dat doet

[joopst]

code:

   DECLARE @str AS VARCHAR(20)
   SET @str = '1234567890abcdefghijklmnopqrstuvwxyz'

   PRINT @str

geeft ook geen error

dus het probleem zit EGT in de database

[joopst]

ik heb nog even getest, maar ook met char geen error

[P_de_B]

Als je parameter niet lang genoeg is wordt er gewoon getruncate, echter probeer je een te lange waarde in de tabel te inserten krijg je wel een foutmelding. (String or binary data would be truncated)

create table test (a varchar(10) )
insert into test (a) values ('1234567891012asv')

Je zult dus de parameter van je stored proc lang genoeg moeten maken, SQL Server test wel op het moment dat een te lange waarde erin komt.

[cannibal]

dan zal het zijn als je een insert doet zoals:


insert tblTest (kolomvan10) values ('0123456789012904090')


Weet zeker dat wij ooit foutmeldingen hebben gekregen. Probleem zat hem toen in de omzettingen van & naar een & amp; waardoor teksten langer werden dan toegestaan.

wel beetje dubbel dit

[ Voor 11% gewijzigd door cannibal op 31-01-2006 14:05 ]

[kenneth]

joopst schreef op dinsdag 31 januari 2006 @ 13:43:

dus het probleem zit EGT in de database

Echt

en het is geen probleem, het is gewoon "behavior by design".
Controleer nu gewoon je invoer. Keep the barbarians out at the gate.

[joopst]

P_de_B schreef op dinsdag 31 januari 2006 @ 13:50:
create table test (a varchar(10) )
insert into test (a) values ('1234567891012asv')

Je zult dus de parameter van je stored proc lang genoeg moeten maken, SQL Server test wel op het moment dat een te lange waarde erin komt.

Wel grappig dat als je dus je parameters hebt gedefinieerd zoals de kolom, dat dan je parameter eerst je waarde verbouwt, en dat dan de verkorte waarde wordt gecontroleerd op de kolombreedte (die dan dus klopt:) )

maar ik kan met niet voorstellen dat daar niet een configuratie optie voor is.. die moet er vast wel zijn.

[P_de_B]

Je definieert toch gewoon je kolom op een maximum lengte? Je kunt dan nooit er een te lange waarde in stoppen.

Je wilt dus blijkbaar via de ene stored proc een veel kortere waarde invoeren?

[joopst]

kenneth schreef op dinsdag 31 januari 2006 @ 13:55:
en het is geen probleem, het is gewoon "behavior by design".
Controleer nu gewoon je invoer. Keep the barbarians out at the gate.

Beste kenneth, ik ben blij dat jij het geen probleem vindt. Dat het behavior by design is klopt ook, omdat het anders niet zo zou werken

maar ik vind het opmerkelijk, zeker als je het verglijkt met hoe andere verglijkbare zaken geregeld zijn bij 'programmeren'.

Kijk maar eens naar de volgende code:

code:

int[] myIntArray = new int[5] { 1, 2, 3, 4, 5, 6 };

gooit ie dan ook 6 gewoon weg ? Volgens mij krijg ik dan meteen om mijn oren dat ik iets verkeerd heb gedaan .. (ik weet het wel zeker eigenlijk)

[joopst]

P_de_B schreef op dinsdag 31 januari 2006 @ 14:13:
Je definieert toch gewoon je kolom op een maximum lengte? Je kunt dan nooit er een te lange waarde in stoppen.

Je wilt dus blijkbaar via de ene stored proc een veel kortere waarde invoeren?

Ik had een kolom van 150.
En een waarde van lengte 164.
en toen was ik data kwijt .. en toen ben ik op zoek gegaan waarom ik van de db niks te horen heb gekregen.. de oplossing is ook wel voor handen, maar een borging dat er geen data verloren gaat in de sp is er niet. Tenzij je dan dus alle kolommen/parameters maar goed lang maakt . En dat hoeft niet altijd .. ze hebben niet voor niks gemaakt dat je het kan instellen (denk/hoop ik).

[RobIII]

joopst schreef op dinsdag 31 januari 2006 @ 14:18:
[...]
En dat hoeft niet altijd .. ze hebben niet voor niks gemaakt dat je het kan instellen (denk/hoop ik).

Ergens.... _{heel klein beetje ergens...} vind ik het wel raar dat je dan uberhaupt een lengte moet opgeven voor (n)varchar in een SP. Kan je net zo goed niets opgeven:

SQL:

@Param AS VARCHAR

Anderzijds hoor je gewoon te checken wat je je SP in propt voordat je er uberhaupt tegen aan schopt...

Overigens is die "" knop er niet voor niets 2 posts achter elkaar is dus niet nodig

[ Voor 32% gewijzigd door RobIII op 31-01-2006 14:44 ]

[kenneth]

Dit topic is trouwens een goed argument tegen SP's voor CRUD-operaties

Maargoed, het is nu eenmaal zo, en je ontkomt er niet aan om de SP aan te passen volgens het datamodel, en vervolgens de aanroepende code weer op die van de de SP.

[Gé Brander]

kenneth schreef op dinsdag 31 januari 2006 @ 14:44:
Dit topic is trouwens een goed argument tegen SP's voor CRUD-operaties

'CRUD' operaties? Wat is 'CRUD'

Maargoed, het is nu eenmaal zo, en je ontkomt er niet aan om de SP aan te passen volgens het datamodel, en vervolgens de aanroepende code weer op die van de de SP.

amen...

[ Voor 6% gewijzigd door Gé Brander op 31-01-2006 16:10 ]

[P_de_B]

c70070540 schreef op dinsdag 31 januari 2006 @ 16:10:
[...]

'CRUD' operaties? Wat is 'CRUD'

[...]

amen...

Create Retrieve Update Delete

[joopst]

RobIII schreef op dinsdag 31 januari 2006 @ 14:42:
[...]

Ergens.... _{heel klein beetje ergens...} vind ik het wel raar dat je dan uberhaupt een lengte moet opgeven voor (n)varchar in een SP. Kan je net zo goed niets opgeven:

SQL:

@Param AS VARCHAR

heb je dat wel eens geprobeerd?

code:

   DECLARE @str AS VARCHAR
   SET @str = '1234567890abcdefghijklmnopqrstuvwxyz'

   PRINT @str

dan krijg je:

code:

1

dus ipv alles krijg je het eerste character

[Gé Brander]

Misschien is de default waarde daarvoor wel 1? (Dus als er geen waarde opgegeven wordt, wordt automatisch (n)varchar(1) gebruikt...)

[ Voor 49% gewijzigd door Gé Brander op 31-01-2006 17:44 ]

[RobIII]

joopst schreef op dinsdag 31 januari 2006 @ 16:54:
[...]

heb je dat wel eens geprobeerd?

code:

   DECLARE @str AS VARCHAR
   SET @str = '1234567890abcdefghijklmnopqrstuvwxyz'

   PRINT @str

dan krijg je:

code:

1

dus ipv alles krijg je het eerste character

Ik sprak hypothetisch... "Dan zou je net zo goed..." enz.

[P_de_B]

joopst schreef op dinsdag 31 januari 2006 @ 16:54:
[...]

heb je dat wel eens geprobeerd?

code:

   DECLARE @str AS VARCHAR
   SET @str = '1234567890abcdefghijklmnopqrstuvwxyz'

   PRINT @str

dan krijg je:

code:

1

dus ipv alles krijg je het eerste character

Default waarde is inderdaad 1.