September 5, 2003 at 12:17 am
"... but replace all the 'IS NOT NULL' statements with '!=NULL' and ..."
You'll have simular differences when you use the JET-syntax for outer joins on sqlserver.
'*=' does not work in the same way as 'left join' !
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
September 5, 2003 at 4:41 am
Just a thought.
Have you tried explicitly setting ANSI_NULLS off for the connection on both to see if the behavior remains the same? This will at least tell us if the problem is whether or not ANSI_NULLS is truely off or it is being turned on somewhere.
September 5, 2003 at 4:48 am
How do I do that through Enterprise Manager?
September 5, 2003 at 8:04 am
Check this possibility...
If you created the routines in the development database, they were created with ANSI_NULLS off. If you used EM to script out the routines and promote them to the production database, the generated script sets ANSI_NULLS on. The setting in effect at the time the routines were created controls how the routines behave. The best bet is to use IS NULL and/or IS NOT NULL to avoid being subject to the ANSI_NULLS setting.
Brian
Edited by - Wingenious on 09/05/2003 08:04:41 AM
Creator of SQLFacts, a free suite of tools for SQL Server database professionals.
September 5, 2003 at 8:21 am
Sorry I meant in you ASP.NET do a query call to do 'SET ANSI_NULL OFF' this will remain in effect for the duration of the connection. After that is run see if you still have the same issues, if not then Wingenious may be barking up the right tree. If does work then something is interferring with the ASP.NET connection somewhere.
September 5, 2003 at 9:04 am
I had similar problem with my Developer and Production environment when I used count function with (IS Not Null) condition in the where clause then I released that Developer server has service pack 2 but Production service pack 3a.
Here is the article related to that issue
http://support.microsoft.com/default.aspx?scid=kb;en-us;814509
The service pack 3 or 3a cause that problem.
September 5, 2003 at 9:17 am
quote:
I had similar problem with my Developer and Production environment when I used count function with (IS Not Null) condition in the where clause then I released that Developer server has service pack 2 but Production service pack 3a.Here is the article related to that issue
http://support.microsoft.com/default.aspx?scid=kb;en-us;814509
The service pack 3 or 3a cause that problem.
But again both are the same server and instance if you look at his connection and read his comments. Is this not right McDavis?
September 5, 2003 at 10:18 am
Yes, that's right. Both databases are on the same instance and the same server.
September 8, 2003 at 10:33 am
quote:
Yes, that's right. Both databases are on the same instance and the same server.
Hi!
I think your problems come from the ANSI_NULLS options used when you created your SP/UDF. These (SPs and UDFs) don't use the "ANSI_NULLS" settings of the connections. Instead, they execute with the values of ANSI_NULLS settings used when they are created. So, if you create a SP with ANSI_NULLS ON, the SP will always use the ANSI_NULLS ON setting. Even if you try to override the settings in the DB or connection. All you have to do to correct this is make sure you use the same ANSI_NULLS settings when creating your SPs.
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply