Incorrect Time Zone

I have just setup up SQL Notification Services 2005 at my workplace and running an instance of it. The problem that I am facing is with the deliveryrequesttime and sent time in the notification distribution view. These times are ahead of the server time by 5 hours. The server is set correctly to the local time and time zone. I would like to synchronize the deliveryrequesttime and senttime to the server time.

TIA

SSNS processes everything in UTC time. I'm guessing you are offset from the UTC by 5 hours.|||How do I go about solving this problem? Is there a setting that I modify?|||I understand from your original post that you'd like to make SSNS process things in accordance with your local time zone. But SSNS works in terms of UTC so that it can process scheduled subscriptions for multiple time zones.

What are you trying to accomplish? If it's for reporting purposes, you can calculate the offset.

HTH...

Joe|||

This was the concrete answer i was looking for.

Thanks

Tha

Incorrect Time Zone

I have just setup up SQL Notification Services 2005 at my workplace and running an instance of it. The problem that I am facing is with the deliveryrequesttime and sent time in the notification distribution view. These times are ahead of the server time by 5 hours. The server is set correctly to the local time and time zone. I would like to synchronize the deliveryrequesttime and senttime to the server time.

TIA

SSNS processes everything in UTC time. I'm guessing you are offset from the UTC by 5 hours.|||How do I go about solving this problem? Is there a setting that I modify?|||I understand from your original post that you'd like to make SSNS process things in accordance with your local time zone. But SSNS works in terms of UTC so that it can process scheduled subscriptions for multiple time zones.

What are you trying to accomplish? If it's for reporting purposes, you can calculate the offset.

HTH...

Joe|||

This was the concrete answer i was looking for.

Thanks

Tha

sql

Incorrect Time Zone

I have just setup up SQL Notification Services 2005 at my workplace and running an instance of it. The problem that I am facing is with the deliveryrequesttime and sent time in the notification distribution view. These times are ahead of the server time by 5 hours. The server is set correctly to the local time and time zone. I would like to synchronize the deliveryrequesttime and senttime to the server time.

TIA

SSNS processes everything in UTC time. I'm guessing you are offset from the UTC by 5 hours.|||How do I go about solving this problem? Is there a setting that I modify?|||I understand from your original post that you'd like to make SSNS process things in accordance with your local time zone. But SSNS works in terms of UTC so that it can process scheduled subscriptions for multiple time zones.

What are you trying to accomplish? If it's for reporting purposes, you can calculate the offset.

HTH...

Joe|||

This was the concrete answer i was looking for.

Thanks

Tha

Incorrect Time Zone

I have just setup up SQL Notification Services 2005 at my workplace and running an instance of it. The problem that I am facing is with the deliveryrequesttime and sent time in the notification distribution view. These times are ahead of the server time by 5 hours. The server is set correctly to the local time and time zone. I would like to synchronize the deliveryrequesttime and senttime to the server time.

TIA

SSNS processes everything in UTC time. I'm guessing you are offset from the UTC by 5 hours.|||How do I go about solving this problem? Is there a setting that I modify?|||I understand from your original post that you'd like to make SSNS process things in accordance with your local time zone. But SSNS works in terms of UTC so that it can process scheduled subscriptions for multiple time zones.

What are you trying to accomplish? If it's for reporting purposes, you can calculate the offset.

HTH...

Joe|||

This was the concrete answer i was looking for.

Thanks

Tha

Incorrect data in sysdatabases compatability level column

Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksPlease ignore this one, I resubmitted this same ticket the to SQL Server
category of threads.
"paul" wrote:

> Hello,
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is
in
> 8.0 compatability, but you get an error message when running the query whi
ch
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>

Incorrect data in sysdatabases compatability level column

Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanks
Sorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:

> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>
|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:

>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
>8.0 compatability, but you get an error message when running the query which
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>

Incorrect data in sysdatabases compatability level column

Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanks
Please ignore this one, I resubmitted this same ticket the to SQL Server
category of threads.
"paul" wrote:

> Hello,
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>

Incorrect data in sysdatabases compatability level column

Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksSorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:
> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
> 8.0 compatability, but you get an error message when running the query which
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:
>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
>8.0 compatability, but you get an error message when running the query which
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>

Incorrect data in sysdatabases compatability level column

Hello,
I've noticed that if you have model and tempdb to different compatability
levels and restart the sql instance, the value in sysdatabases (cmptlevel)
does not get changed correctly.
Here's how to reproduce:
1. set model compatability to one level, say 9.0
2. set tempdb compatability to diff. level, say 8.0
3. verify in SSMS db -> properties -> options
or select * from master..sysdatabases
4. run an old join query from tempdb to show it is actually in 8.0
compatability
-> select * from sysobjects o, syscolumn c where o.id *= c.id
if it runs, the compatability is set to 8.0
5. now restart your db instance
6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is in
8.0 compatability, but you get an error message when running the query which
means the database is in 9.0
Can anyone explain? or is it possible this is a bug?
thanksSorry, I forgot to tell you to run the test query below from the tempdb to
either produce an error message or not. The connection's current db
determines compatability level.
"paul" wrote:

> Hello,
>
> I've noticed that if you have model and tempdb to different compatability
> levels and restart the sql instance, the value in sysdatabases (cmptlevel)
> does not get changed correctly.
> Here's how to reproduce:
> 1. set model compatability to one level, say 9.0
> 2. set tempdb compatability to diff. level, say 8.0
> 3. verify in SSMS db -> properties -> options
> or select * from master..sysdatabases
> 4. run an old join query from tempdb to show it is actually in 8.0
> compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
> 5. now restart your db instance
> 6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is
in
> 8.0 compatability, but you get an error message when running the query whi
ch
> means the database is in 9.0
> Can anyone explain? or is it possible this is a bug?
> thanks
>
>|||For what it is worth, I would not mess with the compatibilty level of
either tempdb or model. I know the idea is that you can set model to
match what you want from a new database, but as tempdb is effectively
recreated from model each time SQL Server starts it sounds like asking
for trouble.
Roy Harvey
Beacon Falls, CT
On Mon, 16 Jul 2007 11:14:08 -0700, paul
<paul@.discussions.microsoft.com> wrote:

>Hello,
>
>I've noticed that if you have model and tempdb to different compatability
>levels and restart the sql instance, the value in sysdatabases (cmptlevel)
>does not get changed correctly.
>Here's how to reproduce:
>1. set model compatability to one level, say 9.0
>2. set tempdb compatability to diff. level, say 8.0
>3. verify in SSMS db -> properties -> options
>or select * from master..sysdatabases
>4. run an old join query from tempdb to show it is actually in 8.0
>compatability
> -> select * from sysobjects o, syscolumn c where o.id *= c.id
> if it runs, the compatability is set to 8.0
>5. now restart your db instance
>6. repeat step 3 and 4, you should see that sysdatabases thinks tempdb is i
n
>8.0 compatability, but you get an error message when running the query whic
h
>means the database is in 9.0
>Can anyone explain? or is it possible this is a bug?
>thanks
>

In with Like

Hi all,
I would like to limit a field using a where clause then use a wildcard
search to further limit the values.
For instance using PUBS:
SELECT *
FROM authors
WHERE (au_fname IN (LIKE ‘ Jo % ’, LIKE ‘ Bill % ’))
In other words allowing me to choose a wildcard from a subset of the original.
Any ideas? Most grateful.
Sam
SELECT au_fname
FROM authors
WHERE au_fname LIKE 'Jo %'
OR au_fname LIKE 'Bill %'
or:
SELECT au_fname
FROM authors,
(SELECT 'Jo %' UNION ALL
SELECT 'Bill %') AS T(fname)
WHERE au_fname LIKE T.fname
David Portas
SQL Server MVP
|||Hi Sam,
The WHERE clause with a condition is used to filter the rows from a given
table. Just using WHERE clause doesn't limit the field (as mentioned by you).
I guess you are looking at something like this:
SELECT *
FROM authors
WHERE (au_fname LIKE 'Jo%' OR au_fname LIKE 'Bill%')
Thanks
Yogish

In with Like

Hi all,
I would like to limit a field using a where clause then use a wildcard
search to further limit the values.
For instance using PUBS:
SELECT *
FROM authors
WHERE (au_fname IN (LIKE ‘ Jo % ’, LIKE ‘ Bill % ’))
In other words allowing me to choose a wildcard from a subset of the origina
l.
Any ideas? Most grateful.
SamSELECT au_fname
FROM authors
WHERE au_fname LIKE 'Jo %'
OR au_fname LIKE 'Bill %'
or:
SELECT au_fname
FROM authors,
(SELECT 'Jo %' UNION ALL
SELECT 'Bill %') AS T(fname)
WHERE au_fname LIKE T.fname
David Portas
SQL Server MVP
--|||Hi Sam,
The WHERE clause with a condition is used to filter the rows from a given
table. Just using WHERE clause doesn't limit the field (as mentioned by you)
.
I guess you are looking at something like this:
SELECT *
FROM authors
WHERE (au_fname LIKE 'Jo%' OR au_fname LIKE 'Bill%')
Thanks
Yogish

In with Like

Hi all,
I would like to limit a field using a where clause then use a wildcard
search to further limit the values.
For instance using PUBS:
SELECT *
FROM authors
WHERE (au_fname IN (LIKE â' Jo % â', LIKE â' Bill % â'))
In other words allowing me to choose a wildcard from a subset of the original.
Any ideas? Most grateful.
SamSELECT au_fname
FROM authors
WHERE au_fname LIKE 'Jo %'
OR au_fname LIKE 'Bill %'
or:
SELECT au_fname
FROM authors,
(SELECT 'Jo %' UNION ALL
SELECT 'Bill %') AS T(fname)
WHERE au_fname LIKE T.fname
--
David Portas
SQL Server MVP
--|||Hi Sam,
The WHERE clause with a condition is used to filter the rows from a given
table. Just using WHERE clause doesn't limit the field (as mentioned by you).
I guess you are looking at something like this:
SELECT *
FROM authors
WHERE (au_fname LIKE 'Jo%' OR au_fname LIKE 'Bill%')
--
Thanks
Yogish