---

Følgende virker fint i min Query Analyzer:

Select Count(OrdreID) as cID, OrdreiD
From vSpotLen
Where DatePart(hh, StartTid)=8
Group By OrdreID

I min kode ser det så således ud:

rs1.Open "Select Count(OrdreID) as cID, OrdreiD From vSpotLen" & _
"Where DatePart(hh, StartTid)=" & x & " Group By
OrdreID", con, adOpenStatic, adLockOptimistic

Det virker så til gengæld ikke. Får fejlen:

'hh' is not a recognized OPTIMIZER LOCK HINTS option"

Har fræst google igennem, men synes ikke jeg kunne finde noget der
passede min lille ting....

Any ideas?


mvh /Snedker
---
Klip det citerede væk, du ikke besvarer
Besvar venligst under det citerede

---

Hmm.... ved ikke hvad din fejl betyder...men prøv at skrive 'h' istedet for
hh....
/Lars

---

Som svar på skriblerier nedfældet af Snedker :

> rs1.Open "Select Count(OrdreID) as cID, OrdreiD From vSpotLen" & _
> "Where DatePart(hh, StartTid)=" & x & " Group By
> OrdreID", con, adOpenStatic, adLockOptimistic
>
> Det virker så til gengæld ikke. Får fejlen:
>
Prøv lige at hente den Select statement fra debuggeren eller vha Profileren
Det ser ud som om du prøver noget ala

Select Count(OrdreID) as cID, OrdreiD
From vSpotLenWhere DatePart(hh, StartTid)=" & x & "
Group By OrdreID

Hvor tabellen får aliaset DatePart og hh bliver "lock hint"

mvh/Peter Lykkegaard

---

On Tue, 29 Oct 2002 08:05:41 +0100, "Peter Lykkegaard"
<polonline@hot.mail.com> wrote:

>Select Count(OrdreID) as cID, OrdreiD
>From vSpotLenWhere DatePart(hh, StartTid)=" & x & "
>Group By OrdreID

Jeeee! Der mangler et mellemrum mellem mit From og Where clause.


mvh /Snedker
---
Klip det citerede væk, du ikke besvarer
Besvar venligst under det citerede

---

Som svar på skriblerier nedfældet af Snedker :

> Jeeee! Der mangler et mellemrum mellem mit From og Where clause.
>
>
Godt set

Hver eneste gang man snubler over en SQL statement der ikke _burde_ fejle,
så kan man få megen hjælp ved at have Profileren kørende, for opsnappe hvad
der bliver sendt til MSSQL

Skriv dette ti gange på en kridttavle hver aften før du går i seng, indtil
du starter Profileren per automatik, når du laver tests

mvh/Peter Lykkegaard

---

On Tue, 29 Oct 2002 13:47:09 +0100, "Peter Lykkegaard"
<polonline@hot.mail.com> wrote:

>Hver eneste gang man snubler over en SQL statement der ikke _burde_ fejle,
>så kan man få megen hjælp ved at have Profileren kørende, for opsnappe hvad
>der bliver sendt til MSSQL

Ja - bortset fra at mit statement aldrig nåede frem til Profileren..?
Under hvilken event burde jeg se det? Jeg har alt under TSQL med...

mvh /Snedker
---
Klip det citerede væk, du ikke besvarer
Besvar venligst under det citerede

---

Som svar på skriblerier nedfældet af Snedker :

> On Tue, 29 Oct 2002 13:47:09 +0100, "Peter Lykkegaard"
> <polonline@hot.mail.com> wrote:
>
>> Hver eneste gang man snubler over en SQL statement der ikke _burde_
>> fejle, så kan man få megen hjælp ved at have Profileren kørende, for
>> opsnappe hvad der bliver sendt til MSSQL
>
> Ja - bortset fra at mit statement aldrig nåede frem til Profileren..?
> Under hvilken event burde jeg se det? Jeg har alt under TSQL med...
>
Øhh, damn
Er det 7 eller 2K?
Og brugte du (profiler) wizarden, eller?
Kan du se andre statements fra din app?

Når du får den fejlmeddelsen du får, så burde du også se den i profileren
"før" den når MSSQL

mvh/Peter Lykkegaard

---

On Tue, 29 Oct 2002 14:35:30 +0100, "Peter Lykkegaard"
<polonline@hot.mail.com> wrote:


>> Ja - bortset fra at mit statement aldrig nåede frem til Profileren..?
>> Under hvilken event burde jeg se det? Jeg har alt under TSQL med...
>>
>Øhh, damn
>Er det 7 eller 2K?
2K

>Og brugte du (profiler) wizarden, eller?
Jeps.
>Kan du se andre statements fra din app?
Jeps


>Når du får den fejlmeddelsen du får, så burde du også se den i profileren
>"før" den når MSSQL

Ja, det skulle jeg jo også mene..

mvh /snedker
---
Klip det citerede væk, du ikke besvarer
Besvar venligst under det citerede

---

Som svar på skriblerier forfattet af Snedker

> On Tue, 29 Oct 2002 14:35:30 +0100, "Peter Lykkegaard"
> <polonline@hot.mail.com> wrote:
>
>> Når du får den fejlmeddelsen du får, så burde du også se den i
>> profileren "før" den når MSSQL
>
> Ja, det skulle jeg jo også mene..
>
Hmm, bruger ODBC eller OLEDB - eller?

mvh/Peter Lykkegaard

---

Hej.

"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:apmq2n$sof$1@sunsite.dk...
> Som svar på skriblerier forfattet af Snedker
>
> > On Tue, 29 Oct 2002 14:35:30 +0100, "Peter Lykkegaard"
> > <polonline@hot.mail.com> wrote:
> >
> >> Når du får den fejlmeddelsen du får, så burde du også se den i
> >> profileren "før" den når MSSQL

Profileren er en tilbagemelding fra serveren, ok IKKE en intercept fra
klient.
Som du skriver, er det et uvurderligt værktøj hvis man bruger M$ SQLServer,
men det er ikke et debugger værktøj.
Debug gøres ved at skrive statementet ud, og derefter kopiere det over i
Query Analyzer.

> > Ja, det skulle jeg jo også mene..
> >
> Hmm, bruger ODBC eller OLEDB - eller?

Not relevant, se ovenstående.

--

Med venlig hilsen/Best regards
Stig Johansen
Stig.Johansen@udvikling.it.dk
(remove dot dk)

---

Som svar på skriblerier nedfældet af Stig Johansen :

> Profileren er en tilbagemelding fra serveren, ok IKKE en intercept fra
> klient.

Hmm, uanset hvor meget skod jeg laver i mine statements så kan jeg se dem i
profileren
Det kan også være at jeg husker totalt forkert og jeg henter SQL strengen
fra script debuggeren
Jeg vil lige prøve det af i løbet af i dag

> Som du skriver, er det et uvurderligt værktøj hvis man bruger M$
> SQLServer, men det er ikke et debugger værktøj.

Nej, det har jeg heller ikke påstået

> Debug gøres ved at skrive statementet ud, og derefter kopiere det
> over i Query Analyzer.
>
Jeps, jeg plejer at kopiere den fra Profileren eller Script Debuggerens
intermediate vindue

>>> Ja, det skulle jeg jo også mene..
>>>
>> Hmm, bruger ODBC eller OLEDB - eller?
>
> Not relevant, se ovenstående.
>
Hmmm, jeg tænkte at ODBC driveren måske returnede den fejl Snedker fik?
Anyway som sagt vil jeg lige prøve det af

mvh/Peter Lykkegaard

---

Som svar på skriblerier forfattet af Stig Johansen

> Profileren er en tilbagemelding fra serveren, ok IKKE en intercept fra
> klient.
> Som du skriver, er det et uvurderligt værktøj hvis man bruger M$
> SQLServer, men det er ikke et debugger værktøj.
> Debug gøres ved at skrive statementet ud, og derefter kopiere det
> over i Query Analyzer.
>
Du kan faktisk snildt få mange af de informationer som QA tilbyder frem i
Profileren
Fx execution plans/statistics, tablescans, duration etc

Når du nu siger debugger er det så T-SQL Debuggeren i Visual Studio du
tænker på eller?

mvh/Peter Lykkegaard

---

Hej.

Ja, det var måske lidt kort formuleret, men jeg havde lidt travlt.
Jeg prøver at uddybe lidt hvad tanken var.

"Peter Lykkegaard" <polonline@hotmail.com> wrote in message
news:appfvl$su3$1@sunsite.dk...
> Som svar på skriblerier forfattet af Stig Johansen
>
> > Profileren er en tilbagemelding fra serveren, ok IKKE en intercept fra
> > klient.

Dette var en hjælp til overblik til alle. Det var for at fortælle, at
profileren ikke nødvendigvis behøver at køre på samme klient.

> > Som du skriver, er det et uvurderligt værktøj hvis man bruger M$
> > SQLServer, men det er ikke et debugger værktøj.

Det her var for at give dig ret i, at det er et godt værktøj.

> > Debug gøres ved at skrive statementet ud, og derefter kopiere det
> > over i Query Analyzer.

Det her var i virkeligheden et råd til at gøre udviklingen nemmere. Hvis man
gør det under udviklingen, har man mulighed for løbende at checke sine
statements, men også kvalitetssikre sine svartider, evt. køre en index
analyse osv.

> Når du nu siger debugger er det så T-SQL Debuggeren i Visual Studio du
> tænker på eller?

Jeg tænkte debug som begreb.

--

Med venlig hilsen/Best regards
Stig Johansen
Stig.Johansen@udvikling.it.dk
(remove dot dk)

---

Som svar på skriblerier nedfældet af Stig Johansen :

> Ja, det var måske lidt kort formuleret, men jeg havde lidt travlt.
> Jeg prøver at uddybe lidt hvad tanken var.



>
> "Peter Lykkegaard" <polonline@hotmail.com> wrote in message
> news:appfvl$su3$1@sunsite.dk...
>> Som svar på skriblerier forfattet af Stig Johansen
>>
>>> Profileren er en tilbagemelding fra serveren, ok IKKE en intercept
>>> fra klient.
>
> Dette var en hjælp til overblik til alle. Det var for at fortælle, at
> profileren ikke nødvendigvis behøver at køre på samme klient.
>
Ja det er korrekt
Profileren giver en hvis belastning på serveren
Kan være en fordel at køre den på en anden box, hvos/når serveren er ved at
dø pga tablescans og man har være et skodhoved
Liden tue kan vælte stort læs

>>> Debug gøres ved at skrive statementet ud, og derefter kopiere det
>>> over i Query Analyzer.
>
> Det her var i virkeligheden et råd til at gøre udviklingen nemmere.
> Hvis man gør det under udviklingen, har man mulighed for løbende at
> checke sine statements, men også kvalitetssikre sine svartider, evt.
> køre en index analyse osv.

Du kan køre få svartiderne direkte og lave indexanalyse i Profileren
Overtid kan man samle et load i profileren og laden den gnaske loadet
igennem efterfølgende
Det giver en mere præcis ananlyse end QA kan tilbyde - imho
>
>> Når du nu siger debugger er det så T-SQL Debuggeren i Visual Studio
>> du tænker på eller?
>
> Jeg tænkte debug som begreb.
>
Det er ikke lige det jeg forstår ved debugning
Ved debugning går man ind i sourcen og kan analysere/ændre værdier i
variabler etc

Her er print statements i øvrigt ganske gode - man skal bare huske at fjene
dem igen - ellers får man multiple recordsets i VB/ADO

---

Hej.

"Peter Lykkegaard" <polonline@hot.mail.com> wrote in message
news:_y4w9.4$741.385@news.get2net.dk...
> > Jeg tænkte debug som begreb.
> >
> Det er ikke lige det jeg forstår ved debugning
> Ved debugning går man ind i sourcen og kan analysere/ændre værdier i
> variabler etc

Ja, eller man kan skrive variabler ud på stdout/stdlist osv..
Den kryptiske bemærkning gik ud på, at hvis man laver ordentlig kode, så har
man ikke brug for debugging.

--

Med venlig hilsen/Best regards
Stig Johansen
Stig.Johansen@udvikling.it.dk
(remove dot dk)

---

Som svar på skriblerier forfattet af Snedker

> On Tue, 29 Oct 2002 13:47:09 +0100, "Peter Lykkegaard"
> <polonline@hot.mail.com> wrote:
>
>> Hver eneste gang man snubler over en SQL statement der ikke _burde_
>> fejle, så kan man få megen hjælp ved at have Profileren kørende, for
>> opsnappe hvad der bliver sendt til MSSQL
>
> Ja - bortset fra at mit statement aldrig nåede frem til Profileren..?
> Under hvilken event burde jeg se det? Jeg har alt under TSQL med...
>
Det er det event der hedder SQL:BatchStarting
Den kommer fint med når jeg lægger den (SQL-sætningen der fejl) ind i min
egen scriptkode
Det virker både fra QA og VBScript via OLEDB

Normalt bruger jeg den template der hedder SQLProfilerTSQL
Du skifter template i Tools -> Options -> General -> Template Name

Jeg sad lige og legede med de forskellige templates og oprettede bland andet
en ny, man kan fakstisk få Execution Plan og andre debuginformationer vist i
Profileren, cool

Indtil nu har jeg "bare" brugt den til at cache SQLstatements så jeg kan
arbejde videre med dem i QA

mvh/Peter Lykkegaard