---

Hej alle.

Jeg er stødt på et underligt problem med en SQL Server. Jeg sidder og
udvikler på en lokal SQL Server, samtidig har jeg en SQL Server ude af
huset, altså ved hosting firmaet. Hvis jeg kører den stored procedure som
hedder "sp_databases" ude af huset, så kører den fint igennem, og returnerer
en liste over databaserne på serveren som den skal. Men hvis jeg kører den
lokalt i Query Analyzer, så får jeg en fejlmeddelelse. Denne fejlmeddelelse
får jeg også når jeg kører den igennem ASP eller Enterprise Manager.
Beskeden lyder således:

Server: Msg 170, Level 15, State 1, Line 2

Line 2: Incorrect syntax near ''.

Server: Msg 170, Level 15, State 1, Line 2

Line 2: Incorrect syntax near ''.

Stored Procedure: master.dbo.sp_databases

Return Code = 0


Koden der kommer til at stå i Query Analyzer er følgende:
USE [master]

DECLARE @RC int <--------- Denne linie siger den fejlen(e) opstår i.

EXEC @RC = [dbo].[sp_databases]

DECLARE @PrnLine nvarchar(4000)

PRINT 'Stored Procedure: master.dbo.sp_databases'

SELECT @PrnLine = ' Return Code = ' + CONVERT(nvarchar, @RC)

PRINT @PrnLine


Det har virket før, og jeg kan ikke umiddelbart huske nogen ændringer på
hverken SQL Server eller serverens opsætning. Det er en Win2k server det
kører på, og det er SQL Server 2000, mener det er version 7 eller 8, det kan
jeg ikke lige huske.

Har i nogen forslag til hvad problemet kan være?

Mvh Mark

--
www.improve.dk

---

Som svar på skriblerier nedfældet af Mark S. Rasmussen :

> Hvis jeg kører den stored procedure som hedder "sp_databases"
> ude af huset, så kører den fint igennem, og returnerer en liste
> over databaserne på serveren som den skal.

> Men hvis jeg kører den lokalt i Query Analyzer, så får jeg en
> fejlmeddelelse.

> Server: Msg 170, Level 15, State 1, Line 2
> Line 2: Incorrect syntax near ''.
>
Hmm, den kører fint på min NT4server/MSSQL7 og Win2KServer/MSSQL2K
Du er sikker på at du ikke ved en fejl har overskrevet sp_databases?

Teksten (sp_databases fra min MSSQL2K) er her til sammenligning, prøv at
køre den fra QA
---------------------------------------------------------
set nocount on
declare @name sysname
declare @SQL nvarchar(600)

/* Use temporary table to sum up database size w/o using group by */
create table #databases (
DATABASE_NAME sysname NOT NULL,
size int NOT NULL)

declare c1 cursor for
select name from master.dbo.sysdatabases
where has_dbaccess(name) = 1 -- Only look at databases to which we have
access

open c1
fetch c1 into @name

while @@fetch_status >= 0
begin
select @SQL = 'insert into #databases
select N'''+ @name + ''', sum(size) from '
+ QuoteName(@name) + '.dbo.sysfiles'
/* Insert row for each database */
execute (@SQL)
fetch c1 into @name
end
deallocate c1

select
DATABASE_NAME,
DATABASE_SIZE = size*8,/* Convert from 8192 byte pages to K */
REMARKS = convert(varchar(254),null) /* Remarks are NULL */
from #databases
order by 1
---------------------------------------------------------

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hot.mail.com> wrote in message
news:R8BS9.10095$4n3.4906@news.get2net.dk...
> Som svar på skriblerier nedfældet af Mark S. Rasmussen :
>
> > Hvis jeg kører den stored procedure som hedder "sp_databases"
> > ude af huset, så kører den fint igennem, og returnerer en liste
> > over databaserne på serveren som den skal.
>
> > Men hvis jeg kører den lokalt i Query Analyzer, så får jeg en
> > fejlmeddelelse.
>
> > Server: Msg 170, Level 15, State 1, Line 2
> > Line 2: Incorrect syntax near ''.
> >
> Hmm, den kører fint på min NT4server/MSSQL7 og Win2KServer/MSSQL2K
> Du er sikker på at du ikke ved en fejl har overskrevet sp_databases?
>
> Teksten (sp_databases fra min MSSQL2K) er her til sammenligning, prøv at
> køre den fra QA

Jeg er ikke lige på arbejde i dag, så jeg kan ikke tjekke det. Men den kører
også fint på min lokale maskine her, WinXP. Det første jeg tænkte på var
også om sp'en måske var blevet modificeret, men hvis jeg åbner den, så er
selve redigeringsvinduet disabled, og jeg kan derfor ikke ændre på den. Jeg
ved så ikke om den evt. kan ændres på pr. kode? Men det kommer man jo næppe
lige til...

Jeg må lige prøve at sammenligne den virkende sp's kode med den ikke
virkendes i morgen.

Mvh Mark
--
www.improve.dk

---

Som svar på skriblerier forfattet af Mark S. Rasmussen

> Jeg må lige prøve at sammenligne den virkende sp's kode med den ikke
> virkendes i morgen.

Check også evt rettighederne for den user account du connecter med

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:3e1b1d48$0$47416$edfadb0f@dtext01.news.tele.dk...
> Som svar på skriblerier forfattet af Mark S. Rasmussen
>
> > Jeg må lige prøve at sammenligne den virkende sp's kode med den ikke
> > virkendes i morgen.
>
> Check også evt rettighederne for den user account du connecter med

Jeg har prøvet at connecte med både "sa" samt en normal databasebruger (med
adgang til masters databasen).

Mvh Mark

---

> Hmm, den kører fint på min NT4server/MSSQL7 og Win2KServer/MSSQL2K
> Du er sikker på at du ikke ved en fejl har overskrevet sp_databases?
>
> Teksten (sp_databases fra min MSSQL2K) er her til sammenligning, prøv at
> køre den fra QA
> ---------------------------------------------------------
> set nocount on
> declare @name sysname
> declare @SQL nvarchar(600)
>
> /* Use temporary table to sum up database size w/o using group by */
> create table #databases (
> DATABASE_NAME sysname NOT NULL,
> size int NOT NULL)
>
> declare c1 cursor for
> select name from master.dbo.sysdatabases
> where has_dbaccess(name) = 1 -- Only look at databases to which we have
> access
>
> open c1
> fetch c1 into @name
>
> while @@fetch_status >= 0
> begin
> select @SQL = 'insert into #databases
> select N'''+ @name + ''', sum(size) from '
> + QuoteName(@name) + '.dbo.sysfiles'
> /* Insert row for each database */
> execute (@SQL)
> fetch c1 into @name
> end
> deallocate c1
>
> select
> DATABASE_NAME,
> DATABASE_SIZE = size*8,/* Convert from 8192 byte pages to K */
> REMARKS = convert(varchar(254),null) /* Remarks are NULL */
> from #databases
> order by 1

Den har jeg nu prøvet at køre, og sammenligne med teksten i den sp jeg
har her på serveren. De er 100% identiske, men jeg får stadig samme
fejl som jeg nævnte i første post. Nogen idéer?

---

Som svar på skriblerier nedfældet af Mark S. Rasmussen :

> Den har jeg nu prøvet at køre, og sammenligne med teksten i den sp jeg
> har her på serveren. De er 100% identiske, men jeg får stadig samme
> fejl som jeg nævnte i første post

Får du også en fejl når du kører koden (der ligger indkapslet i
sp_databases) i QA?

mvh/Peter Lykkegaard

---

> Får du også en fejl når du kører koden (der ligger indkapslet i
> sp_databases) i QA?

Hej igen.

Når jeg kører koden direkte i QA, så opstår den samme fejl. Den
brokker sig over linie nr. 2, altså den som indeholder "declare @name
sysname". Linie 2 på den virkende sql server er nøjagtig magen til, så
jeg ved ikke rigtig hvad problemet ligger i.

Mvh Mark

---

Som svar på skriblerier nedfældet af Mark S. Rasmussen :

>> Får du også en fejl når du kører koden (der ligger indkapslet i
>> sp_databases) i QA?
>
> Når jeg kører koden direkte i QA, så opstår den samme fejl. Den
> brokker sig over linie nr. 2, altså den som indeholder "declare @name
> sysname". Linie 2 på den virkende sql server er nøjagtig magen til, så
> jeg ved ikke rigtig hvad problemet ligger i.
>
Muligvis problemer med din SQL installation?

Prøv at erstatte sysname [1] med nvarchar(128) i sp_databases
Ved godt at det ikke er en holdbar/langsigtet løsning

mvh/Peter Lykkegaard

[1] fra BOL
"sysname is a system-supplied user-defined data type that is a synonym for
nvarchar(128) and is used to reference database object names."

---

> Muligvis problemer med din SQL installation?
>
> Prøv at erstatte sysname [1] med nvarchar(128) i sp_databases
> Ved godt at det ikke er en holdbar/langsigtet løsning
>
> mvh/Peter Lykkegaard
>
> [1] fra BOL
> "sysname is a system-supplied user-defined data type that is a synonym for
> nvarchar(128) and is used to reference database object names."

Så virker det! Fejlen burde have været rimeligt åbenlys. Der var
oprettet en database som indeholdt en apostrof (') i navnet, spørg mig
endeligt ikke hvordan eller hvorfor. Det havde den tydeligvis noget
svært ved at håndtere, og spyttede derfor denne fejl ud. Nu da
databasen er blevet slettet virker det upåklageligt. Tak for din/jeres
hjælp mht. at finde en fejl som aldrig burde have forekommet :)

Mvh Mark

---

Som svar på skriblerier nedfældet af Mark S. Rasmussen :

> Der var oprettet en database som indeholdt en apostrof (') i
> navnet, spørg mig endeligt ikke hvordan eller hvorfor.

Navne, vi _vil_ have navne

Godt at det lykkedes dig at finde fejlen

mvh/Peter Lykkegaard

---

> > Der var oprettet en database som indeholdt en apostrof (') i
> > navnet, spørg mig endeligt ikke hvordan eller hvorfor.
>
> Navne, vi _vil_ have navne

Tjae, du kender det måske :) "testasddwe'd", noget lignende det... Når man
sidder og tester en stored procedure som skal oprette en database
automatisk, så sidder man bare og bruger alle mulige underlige navne, som
oftest bare kan laves ved at dunke hovedet ned i tastaturet 2-3 gange i
træk.

Man lærer vel af sine fejltagelser, håber jeg :D

Mvh Mark