Re: Null als Parameter in StoredProcedure liefert auf zwei Systeme

Hallo Markus,

"Markus Elsper" schrieb:

> Hallo Christa,
>
> "Christa Kurschat" <ChristaKurschat@xxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im
> Newsbeitrag news:12F559B4-F67C-4526-BF3E-D50318EE209E@xxxxxxxxxxxxxxxx
> > Hallo Markus,
> >
> >
> > Den Wert für Ansi_Nulls kannst Du mit
> > select DATABASEPROPERTYEX( 'DeineDB', 'IsAnsiNullsEnabled' )
> > ermitteln. vergl. OH
> >
> > Gruß
> > Christa
>
> danke, aber auf beiden Maschinen liefert die Abfrage 0, hier kann der
> Unterschied also nicht liegen.
>

Hmmmm....
Seltsam :-)

> Weisst Du evtl. noch was anderes?
>

Diese Option kann für jede Verbindung gesetzt werden.
Wie hast Du das Statement getestet?
Könnte der Client andere Einstellungen haben als die DB?
Wenn QA, schau mal in die Optionen - Verbindungsoptionen

Aber wie auch immer, gerade weil diese Ansi_nulls-Geschichte so unwägbar
ist, solltest Du in Deiner Prozedur sauber arbeiten, also entweder vorher
expliziet setzen, um das gewünschte Verhalten zu erreichen oder mit IS NULL
arbeiten.

Ev. geht ja folgendes:

where
case
when @Parameter is null
then Feld is null
else Feld = @Parameter
end

Oder arbeite mit dyn. SQL:

declare sql varchar(4000)
set @sql = 'select ... from Tabelle where '
if Parameter is null
set @sql = @sql + 'Feld is null'
else
set @sql = @sql + 'Feld = ''' + @Parameter + '''
exec (@sql)

Alles andere wäre mir zu ungewiß.

Gruß
Christa
.

Relevant Pages