Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Compatibility issue and CROSS APPLY


Compatibility issue and CROSS APPLY

Author
Message
Divya Agrawal
Divya Agrawal
SSC Veteran
SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)

Group: General Forum Members
Points: 220 Visits: 604
Comments posted to this topic are about the item Compatibility issue and CROSS APPLY

--Divya
peter-757102
peter-757102
Mr or Mrs. 500
Mr or Mrs. 500 (537 reputation)Mr or Mrs. 500 (537 reputation)Mr or Mrs. 500 (537 reputation)Mr or Mrs. 500 (537 reputation)Mr or Mrs. 500 (537 reputation)Mr or Mrs. 500 (537 reputation)Mr or Mrs. 500 (537 reputation)Mr or Mrs. 500 (537 reputation)

Group: General Forum Members
Points: 537 Visits: 2553
Divya,


Good to mention this problem, its just the title is a little dramatic for those not reading the article as cross apply compatibility is not really broken. But its understandable as this is needed to be found by people that have the described issue.

I have been running into the same thing in the past and lucky for me quickly realized what was the issue as I had the code running in another database with the correct compatibility level before.

It seems as when the database compatibility level is at 80 uses a distinct parser that is unaware of the later additions to the language. Otherwise it would be able to point out that cross apply of a function is not possible given the compatibility setting.

Useful submission!
ta.bu.shi.da.yu
ta.bu.shi.da.yu
SSC Veteran
SSC Veteran (285 reputation)SSC Veteran (285 reputation)SSC Veteran (285 reputation)SSC Veteran (285 reputation)SSC Veteran (285 reputation)SSC Veteran (285 reputation)SSC Veteran (285 reputation)SSC Veteran (285 reputation)

Group: General Forum Members
Points: 285 Visits: 494
Ummm... good article, but surely as a matter of course you would be careful to check the version being run when using new SQL Server statements? For instance, if you tried to run a recursive CTE, you'd also get the same issue...

Random Technical Stuff
aliinal
aliinal
Forum Newbie
Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)

Group: General Forum Members
Points: 1 Visits: 19
Really time-saver post.
Thanks,
Dave Slee
Dave Slee
SSC-Enthusiastic
SSC-Enthusiastic (134 reputation)SSC-Enthusiastic (134 reputation)SSC-Enthusiastic (134 reputation)SSC-Enthusiastic (134 reputation)SSC-Enthusiastic (134 reputation)SSC-Enthusiastic (134 reputation)SSC-Enthusiastic (134 reputation)SSC-Enthusiastic (134 reputation)

Group: General Forum Members
Points: 134 Visits: 124
I would caution that if you have any deprecated syntax in the database's views and stored procs (SQL-89 joins for example), changing the compatibility mode can cause them to break. You want to carefully consider any changes to your databases' compatibility levels. Just like newer syntax is won't work on older compatibility levels, some deprecated syntax will not work with newer compatibility levels.

If you're not sure whether this applies to your database or not, Microsoft's Upgrade Adviser Utility is a good place to start. Unfortunately, if your applications have a lot of in-line SQL, this process can become significantly more painful.
G33kKahuna
G33kKahuna
Valued Member
Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)

Group: General Forum Members
Points: 72 Visits: 313
Come on; such simple solutions are expected out of novice heads me not brilliant minds like you .... :-)

Changing compatibility is not an option in most cases especially when you are housing a pure 80 DB with 80 specific query constructs or features that are deprecated in 90. Another way to workaround is to create a new DB with compatibility set to 90 and cross query the 80 database.
SanjayAttray
SanjayAttray
SSCarpal Tunnel
SSCarpal Tunnel (4K reputation)SSCarpal Tunnel (4K reputation)SSCarpal Tunnel (4K reputation)SSCarpal Tunnel (4K reputation)SSCarpal Tunnel (4K reputation)SSCarpal Tunnel (4K reputation)SSCarpal Tunnel (4K reputation)SSCarpal Tunnel (4K reputation)

Group: General Forum Members
Points: 4035 Visits: 1619
Kaushik Kumar (8/6/2009)
Come on; such simple solutions are expected out of novice heads me not brilliant minds like you .... :-)

Changing compatibility is not an option in most cases especially when you are housing a pure 80 DB with 80 specific query constructs or features that are deprecated in 90. Another way to workaround is to create a new DB with compatibility set to 90 and cross query the 80 database.


Agreed. -- Create a new DB with compatibility set to 90 and cross query the 80 database on 2005 server. What if application still supports 80 compatibility only and you have to upgrade server from 2000 to 2005 due to business policy/requirement ? Changing compatibility does not looks like an option in above case.

By the way, I am dealing issues / supporting with 3 application right now which are housed on 2005 with compatibility 80.

SQL DBA.
David McKinney
David McKinney
SSC Eights!
SSC Eights! (889 reputation)SSC Eights! (889 reputation)SSC Eights! (889 reputation)SSC Eights! (889 reputation)SSC Eights! (889 reputation)SSC Eights! (889 reputation)SSC Eights! (889 reputation)SSC Eights! (889 reputation)

Group: General Forum Members
Points: 889 Visits: 2090
I've found that you can do a surprising amount of new stuff in a database with compatibility level 8..

I say surprisingly because I didn't expect to be able to use any of the new features of 2005.

I would echo what's been said before that changing the compatibility level from 8 to 9 isn't something you should do without considering the implications. Why was the compatibility 8 to begin with? There may be a\ good reason.
jaroho
jaroho
Forum Newbie
Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)

Group: General Forum Members
Points: 8 Visits: 27
where is the function fn_TopOrders?
How do i create it?

thanks
Great article
Divya Agrawal
Divya Agrawal
SSC Veteran
SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)

Group: General Forum Members
Points: 220 Visits: 604
fn_TopOrders returns the top 3 Orderid,Orderdate from the SalesOrder table. As my issue was not more based upon that i have not included the function..!!

--Divya
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search