Showing posts with label level. Show all posts
Showing posts with label level. Show all posts

Thursday, March 8, 2012

complex tables - want to join to get one row of results from multiple rows

Hi there

This is a hard problem that I have - I have only been using sql for a couple of weeks and have gone past my ability level quickly! The real tables are complex but I will post a simple and a real version with the hope someone can help me.

Any help would be much appreciated - I would also be happy to pay someone to actually do it if it takes time to work out as I know that its hard when all your help is free :)
================================================
SIMPLE VERSION
Table 1 Dog breeds
dogbreedID, dogBreedName, colour
1,labrador,golden
2,beagle, tricolour
3,great dane, marle

Table 2 - maps criteria to dog breeds
dogbreedID, criteriaID, value, location
3,2,easy to train, c:/filepath2
1,1,good with children, c:/filepath
1,2,easy to train, c:/filepath2
2,1,good with children, c:/filepath
3,3,stranger friendly, c:/filepath3

So that leads to table 3 sitting behind the scenes not used in this query:
criteriaID, value, location
1,good with children, c:/filepath
2,easy to train, c:/filepath2
3,stranger friendly, c:/filepath3

I want a view that has the following:
dogbreedID, dogBreedName, colour, criteriaID1, value1, location1, criteriaID2, value2, location2, criteriaID3, value3, location3,criteriaID4, value4, location4

1,labrador,golden,1,good with children, c:/filepath,2,easy to train, c:/filepath2,NULL,NULL,NULL,NULL, NULL, NULL

2,beagle, tricolour,1,good with children,NULL, NULL, NULL,NULL, NULL, NULL,NULL, NULL, NULL

3,great dane, marle,NULL, NULL, NULL,2,easy to train, c:/filepath2,3,stranger friendly, c:/filepath3

================================================== =====
more complicated view - you can see each table is actually a combination of table values but I dont think that matters to this problem - the above example is fine but I am not very good with this so may have left somehting out that you can derive from the example below:
Table 1:
SELECT distinct dbo.BREED_dogBreeds.breedId, dbo.BREED_dogBreeds.breedName, dbo.BREED_dogBreeds.alternativeName, dbo.BREED_dogBreeds.shortDesc,
dbo.BREED_dogBreeds.katShortDesc, dbo.BREED_dogBreeds.longDesc, dbo.BREED_dogBreeds.katLongDesc,
dbo.BREED_dogBreeds.thingsToConsider, dbo.BREED_dogBreeds.temperament, dbo.BREED_dogBreeds.history, dbo.BREED_dogBreeds.feeding,
dbo.BREED_tblCountry.Country_Name, dbo.BREED_dogBreeds.colour, dbo.BREED_dogBreeds.breedProfileLink, dbo.BREED_Grooming.groomText,
dbo.BREED_GroomFrequencyValues.value, dbo.BREED_Training.intelligence, dbo.BREED_Training.trainingNotes, dbo.BREED_Training.exerciseText,
dbo.BREED_Training.exerciseTime, dbo.BREED_Training.timePerDay, dbo.BREED_Suitability.idealOwner, dbo.BREED_Size.size,
dbo.BREED_sizes.bheightmin, dbo.BREED_sizes.bheightmax, dbo.BREED_sizes.bweightmin, dbo.BREED_sizes.bweightmax,
dbo.BREED_sizes.dheightmin, dbo.BREED_sizes.dheightmax, dbo.BREED_sizes.dweightmin, dbo.BREED_sizes.dweightmax,
dbo.BREED_Sociability.compatibility FROM dbo.BREED_Sociability RIGHT OUTER JOIN
dbo.BREED_dogBreeds ON dbo.BREED_Sociability.sociabilityID = dbo.BREED_dogBreeds.sociabilityID LEFT OUTER JOIN
dbo.BREED_Size RIGHT OUTER JOIN
dbo.BREED_sizes ON dbo.BREED_Size.id = dbo.BREED_sizes.sizeid ON
dbo.BREED_dogBreeds.sizeId = dbo.BREED_sizes.breedSizeId LEFT OUTER JOIN
dbo.BREED_Suitability ON dbo.BREED_dogBreeds.suitabilityID = dbo.BREED_Suitability.suitabilityID LEFT OUTER JOIN
dbo.BREED_Training ON dbo.BREED_dogBreeds.trainID = dbo.BREED_Training.trainID LEFT OUTER JOIN
dbo.BREED_GroomFrequencyValues RIGHT OUTER JOIN
dbo.BREED_Grooming ON dbo.BREED_GroomFrequencyValues.gfvID = dbo.BREED_Grooming.gfvID ON
dbo.BREED_dogBreeds.groomID = dbo.BREED_Grooming.groomID LEFT OUTER JOIN
dbo.BREED_tblCountry ON dbo.BREED_dogBreeds.country = dbo.BREED_tblCountry.Country_ID

Table 2:
SELECT [breedId]
,[breedCriteriaID]
,[value]
,[icon]
FROM [v1vw1n_dogmatch].[dbo].[vbreedCriterias]
where levelID>=3
order by breedId, breedCriteriaID asc

TABLE 3
SELECT [breedCriteriaID]
,[criteriaValue]
,[icon]
FROM [v1vw1n_dogmatch].[dbo].[BREED_Criteria]

Table1
186Afghan HoundTazi, Baluchi HoundA strikingly beautiful dog with dignified poise.Afghans are kept primarily as show dogs and can also be used for lure coursing. They are extremely loving and loyal to their owners and are gentle souled and good with children. Afghans can make companion dogs but their considerable needs means that only devoted owners keep them. Aloof with strangers but affectionate and loyal to their owners. Can be very clown like at play and are very people oriented. Love children and being included in family life. Can become introverted if excluded from social situations whilst pups.An ancient breed, the afghan looks as classy as its pedigree. Afghans were used in Afghanistan to protect the flocks and would hunt and kill panthers, leopards and other large predators. The first dog to be shown was in the UK in 1907 having previously been banned from export. Afghans can be fussy with their food and it is better to instill good eating habits when they are pups and ideally treats should be avoided. AfghanistanAfghans are a grooming salons dream come true - they demand regular grooming and can quickly become knotted and tangled without it. DailyAll dogs are bright but Afghans may not quite earn the MENSA of the dog world.Afghans can be hard to train with lots of perseverance needed. Highly strung, stubborn and sensitive natured dog making them difficult to train. Training cannot be rushed and as they are sensitive souls and it is very important not treat them harshly. Sometimes difficult to housebreak. As puppies, Afghans often appear awkward, with uneven growth, gawkiness and loose limbs, and for this reason, exercise must be carefully monitored to avoid injury to their growing bones.00Suitable for the experienced, comitted dog owner with time on their hands and a great love for the breed.large63cm69cm23kg25kg68cm74cm25kg (55lb)28kg (62lb)They are hunting stock and love to chase anything that moves so perhaps not the ideal dog to share a home with cats and small animals!
187Bluetick CoonhoundNULLNot found in Australia, the Bluetick Coonhound is a friendly hound that makes an excellent tracking or scent dog.NULLThis breed originated in the states and has a smooth, dense, tri colour coat. The base colour is white with heavy ticking of black and tan markings over their chest, eyes, muzzle, lower legs and feet. This breed is recognised as a competitive, fearless, dedicated hunter. The Bluetick has a typical hound bawl and so is not the quietest of dogs.NULLThis dog needs a lot of exercise. They love to do jobs, and keep busy. They need to be exercised vigorously or they run the danger of becoming destructive and will howl excessivly.The Coonhound is deeply devoted, fearless, attentive and loyal. They make very good guardians and family companions. They are reserved with strangers, but are not aggressive towards them. They are not the best with other animals, and get along better with older, considerate children.The Bluetick originated in Louisiana at the beginning of the 20th century. They were developed from crosses between the English Coonhound, the Foxhound and the french Grand Bleu de Gascogne. Their tricoloured, blue-speckled coat sets them apart from other Coonhound breeds. Originally they were registered as a variant of the English Coonhound, but in 1946 they were given separate recognition as a distinct breed in their own right.Today the English Coonhound is sometimes referred to as the Redtick. The original, old-fashioned Bluetick dog, which was larger and slower than the modern type, began to loose ground because they did less well in the increasingly popular field competitions and night trials. The smaller, faster version began to eclipse them and became one of the most popular and numerous of all coonhound breeds. This upset the traditionalists, who preferred the old-style Big Blue , and some of them reacted by switching their allegiance to other large-bodied breeds, such as the Blue Gascon, and the Majestic.This breed is not fussy when it comes to their diet, but they have quite a healthy appetite.United States of AmericaNULLNULLNULLNULLNULLNULLNULLNULLNULLNULLNULLNULLNULLNULLNULLNULLNULLNULLNULLNULL
188Australian Cattle DogCattledog, Queensland Heeler, Heeler, Blue Heeler, Red Heeler, BlueyA strong compact working dog, the Australian Cattle Dog is one of the most popular breeds of dog in Australia.A strong compact working dog, the Australian Cattle Dog is one of the most popular breeds of dog in Australia.The Australian Cattle Dog is a strong compact working dog with a combination of substance, power, balance and hard muscular condition that conveys the impression of great agility, strength and endurance with the ability and willingness to carry out his allotted task however arduous. His head is wedge shaped with a broad skull and muscular cheeks and oval shaped, dark brown eyes that express alertness and intelligence and have a warning or suspicious glint when approached by strangers. His ears are broad at base, muscular, pricked and moderately pointed. His rain resistant coat is a smooth double coat with a close, hard outer coat and a short dense undercoat AND comes in two colours: Blue: Blue, blue-mottled or blue speckled with tan markings. Red: An even red speckle all over, including the undercoat, with or without darker red markings on the head. The pups are born white, developing their colour gradually from approximately three weeks of age. The Australian Cattle Dog is a strong compact working dog with a combination of substance, power, balance and hard muscular condition that conveys the impression of great agility, strength and endurance with the ability and willingness to carry out his allotted task however arduous. His head is wedge shaped with a broad skull and muscular cheeks and oval shaped, dark brown eyes that express alertness and intelligence and have a warning or suspicious glint when approached by strangers. His ears are broad at base, muscular, pricked and moderately pointed. His rain resistant coat is a smooth double coat with a close, hard outer coat and a short dense undercoat AND comes in two colours: Blue: Blue, blue-mottled or blue speckled with tan markings. Red: An even red speckle all over, including the undercoat, with or without darker red markings on the head. The pups are born white, developing their colour gradually from approximately three weeks of age. The Australian Cattle Dog has a strong herding instinct and when playing may nip the heels of children.The Australian Cattle Dog needs a job, companionship and activity for the mind and body, all day, every day. Easily bored, he can become noisy and/or destructive. Renowned for his protectiveness and loyalty to master and property, he is very selective as to who is friend or foe. In 1840, Thomas Hall, a landowner in New South Wales, imported two smooth-haired blue merle Scotch Collies and crossed their progeny with the Dingo. The resulting litters became known as Hall's Heelers. The progeny were generally of Dingo type with the colour being either red or blue merle and were valued for their ability to handle wild cattle, stamina to travel great distances over all types of terrain, and their endurance in extremes of temperature. Later, Hall's Heelers were crossed with a Dalmatian, which changed the merle colour to red or blue speckle and instilled in the dogs a love of horses and protectiveness toward master and property. A further cross was made to the Kelpie to produce highly intelligent, controllable workers resembling thickset Dingoes and with peculiar markings known to no other dog. In 1903 a standard for the breed was drawn up and from these beginnings the Australian Cattle Dog has developed into one of the most popular breeds of dog in Australia today. AustraliaMinimal grooming although weekly brushing is required to remove dead hair. Does shed seasonally.Weekly - at homeHe is loving, playful, and eager to please his owner. Very quick to learn.Unless you can give him extensive exercise do not even consider owning an Australian Cattle Dog. He was bred to work all day in hard conditions and will become bored if not given sufficient exercise.602Single guy or gal, athletic, able to have the dog with them most of the time. Not a first time dog owner. Families with older children.medium43cm (17")48cm (19")16kg (35lb)20kg (44lb)46cm (18")51cm (20")16kg (35lb)20kg (44lbs)Not good with dogs of the same sex. OK with cats if raised with the cat since puppyhood. Not good with other small mammals.

TABLE 2
1861suits older children/Images/icons/older_children.gif
1862suits younger children/Images/icons/suits_young_children.gif
1863suits elderly/disabled. Not too boisterous/Images/icons/suits_elderly_disabled.gif
1866easy to transport/Images/icons/transport.gif
1868grooming needs/Images/icons/grooming_needs.gif
18610distress/destruction when left alone/Images/icons/distressed_when_alone.gif
18612Shedding / Hair loss/Images/icons/shedding_hairloss.gif
18615Energy Level/Images/icons/energy_levels.gif
18616Affection with family/Images/icons/affectionate.gif
18622may bite intruder/Images/icons/bite_intruder.gif
18623watchdog skills/Images/icons/watchdog_skills.gif
1871suits older children/Images/icons/older_children.gif
1876easy to transport/Images/icons/transport.gif
18710distress/destruction when left alone/Images/icons/distressed_when_alone.gif
18712Shedding / Hair loss/Images/icons/shedding_hairloss.gif
18713stranger friendly/Images/icons/stranger_friendly.gif
18715Energy Level/Images/icons/energy_levels.gif
18716Affection with family/Images/icons/affectionate.gif
18722may bite intruder/Images/icons/bite_intruder.gif
18723watchdog skills/Images/icons/watchdog_skills.gif
1881suits older children/Images/icons/older_children.gif
1883suits elderly/disabled. Not too boisterous/Images/icons/suits_elderly_disabled.gif
1884cattle friendly/Images/icons/cattle_friendly.gif
1886easy to transport/Images/icons/transport.gif
18810distress/destruction when left alone/Images/icons/distressed_when_alone.gif
18811trainability/Images/icons/trainable.gif
18812Shedding / Hair loss/Images/icons/shedding_hairloss.gif
18813stranger friendly/Images/icons/stranger_friendly.gif
18814How often this breed is found in the pound/Images/icons/found_in_pount.gif
18815Energy Level/Images/icons/energy_levels.gif
18816Affection with family/Images/icons/affectionate.gif
18819Availability/Images/icons/availability.gif
18820cat friendly/Images/icons/cat_friendly.gif
18822may bite intruder/Images/icons/bite_intruder.gif
18823watchdog skills/Images/icons/watchdog_skills.gif
1891suits older children/Images/icons/older_children.gif
1892suits younger children/Images/icons/suits_young_children.gif
1898grooming needs/Images/icons/grooming_needs.gif
18910distress/destruction when left alone/Images/icons/distressed_when_alone.gif
18912Shedding / Hair loss/Images/icons/shedding_hairloss.gif
18913stranger friendly/Images/icons/stranger_friendly.gif
18914How often this breed is found in the pound/Images/icons/found_in_pount.gif
18915Energy Level/Images/icons/energy_levels.gif
18916Affection with family/Images/icons/affectionate.gif
18919Availability/Images/icons/availability.gif
18923watchdog skills/Images/icons/watchdog_skills.gif
1901suits older children/Images/icons/older_children.gif
1903suits elderly/disabled. Not too boisterous/Images/icons/suits_elderly_disabled.gif
1906easy to transport/Images/icons/transport.gif
19010distress/destruction when left alone/Images/icons/distressed_when_alone.gif
19011trainability/Images/icons/trainable.gif
19013stranger friendly/Images/icons/stranger_friendly.gif
19014How often this breed is found in the pound/Images/icons/found_in_pount.gif
19015Energy Level/Images/icons/energy_levels.gif
19016Affection with family/Images/icons/affectionate.gif
19019Availability/Images/icons/availability.gif
19022may bite intruder/Images/icons/bite_intruder.gif
19023watchdog skills/Images/icons/watchdog_skills.gif
19024Gay Icon/Images/icons/gay_icon.gif
1921suits older children/Images/icons/older_children.gif
1922suits younger children/Images/icons/suits_young_children.gif
1923suits elderly/disabled. Not too boisterous/Images/icons/suits_elderly_disabled.gif
1924cattle friendly/Images/icons/cattle_friendly.gif
1925bunny/guinea pig friendly/Images/icons/bunny_friendly.gif
1926easy to transport/Images/icons/transport.gif
19210distress/destruction when left alone/Images/icons/distressed_when_alone.gif
19211trainability/Images/icons/trainable.gif
19212Shedding / Hair loss/Images/icons/shedding_hairloss.gif
19213stranger friendly/Images/icons/stranger_friendly.gif
19215Energy Level/Images/icons/energy_levels.gif
19216Affection with family/Images/icons/affectionate.gif
19217dog friendly/Images/icons/dog_friendly.gif
19219Availability/Images/icons/availability.gif
19220cat friendly/Images/icons/cat_friendly.gif
19223watchdog skills/Images/icons/watchdog_skills.gif

etcHi there

I got a response on another board. Basically I just used
SELECT dogBreedID,
crit1value = MIN(CASE criteriaID WHEN 1 THEN value END),
crit1location = MIN(CASE criteriaID WHEN 1 THEN location END),
crit2value = MIN(CASE criteriaID WHEN 2 THEN value END),
crit2location = MIN(CASE criteriaID WHEN 2 THEN location END),
...
FROM tbl
GROUP BY dogBreedID

and joined that to the first table.

Fantastic!

Wednesday, March 7, 2012

complex 'query' using full text indexing

Hi people

i am having some difficulty with a quite advanced query (at least from my level).

select * from cities join areacodes on contains (city,'select area from areacodes right join cities on area not in (select city from cities)' )


Server: Msg 7631, Level 15, State 1, Line 1
Syntax error occurred near 'area'. Expected ''''' in search condition 'select area from areacodes right join cities on area not in (select city from cities)'.

what i am trying to do is find the areas in the postcodes table that contain words that are in the cities table. I need to match them up and modify the data in the postcodes table. the data is inconsistent as it comes from two unrelated sources. i have to be aware of spelling mistakes etc and have tried usind the soundex function to match them but it produces too many results. as you can see from the data in the postcodes table some areas (the second column) are not entirely upper case. these are the areas that have matched records in the cities table and the data is valid.

please can someone suggest the correct and easy way of doing this?

Thanks

Chris Morton

POSTCODES TABLE FIRST 30 ROWS

1

Aberdeen

49

3450

2

ABERDEEN FARM LINES

49212

3450

3

ABERFELDY

58652

3451

4

ACORNHOEK

13

3454

5

ACORNHOEK FARM LINES

137952

3454

6

Addo

42

3450

7

Adelaide

46

3450

8

Aggeneys

54

3456

9

AKASIA

12

3452

10

Albertinia

28

3458

11

Alberton

11

3452

12

ALETTASRUS

53922

3451

13

Alexander Bay

27

3456

14

Alexandria

46

3450

15

Alice

40

3450

16

ALICE FARM LINES

4049

3450

17

ALICEDALE

42

3450

18

Aliwal North

51

3450

19

Allanridge

57

3451

20

Alldays

15

3457

21

ALMA

14

3455

22

Amalia

53

3455

23

AMANDEBULT

14

3455

24

Amanzimtoti

31

3453

25

AMATIKULU

35

3453

26

Amersfoort

17

3454

27

Amsterdam

17

3454

28

ANERLEY

39

3453

29

APEL

15

3457

30

APEL FARM LINES

15482

3457

CITIES TABLE FIRST 30 ROWS

1

Aberdeen

3450

2

Addo

3450

3

Adelaide

3450

4

Alexandria

3450

5

Alice

3450

6

Aliwal North

3450

7

Balfour

3450

8

Barkly East

3450

9

Bathurst

3450

10

Bedford

3450

11

Bisho

3450

12

Burgersdorp

3450

13

Butterworth

3450

14

Cathcart

3450

15

Cintsa

3450

16

Coffee Bay

3450

17

Cookhouse

3450

18

Cradock

3450

19

Dordrecht

3450

20

East London

3450

21

Elliot

3450

22

Flagstaff

3450

23

Fort Beaufort

3450

24

Gonubie

3450

25

Graaff Reinet

3450

26

Grahamstown

3450

27

Haga-Haga

3450

28

Hamburg

3450

29

Hankey

3450

30

Herschel

3450

Hi Chris,

The only way I can think of that you can leverage CONTAINS/fulltext functionality in this case is unfortunately through a cursor - you'll need to fetch a row from the Cities table and run a CONTAINS query on your Postcodes table per every city you fetch.

If you have a requiement for matching large amounts of "fuzzy" data, you may want to check if Fuzzy Lookup Transform in SSIS could be useful.

Hope this helps.

Best regards,

Friday, February 17, 2012

Compilation error on store procedure

Hi all,
Here is my error: Server: Msg 245, Level 16, State 1, Procedure NewAcctTypeSP, Line 10
Syntax error converting the varchar value'The account type is already exist' to a column of data type int.
Here is my procedure:
ALTER PROC NewAcctTypeSP
(@.acctType VARCHAR(20), @.message VARCHAR (40) OUT)
AS
BEGIN
--checks if the new account type is already exist
IF EXISTS (SELECT * FROM AcctTypeCatalog WHERE acctType = @.acctType)
BEGIN
SET @.message = 'The account type is already exist'
RETURN @.message
END

BEGIN TRANSACTION
INSERT INTO AcctTypeCatalog (acctType) VALUES (@.acctType)
--if there is an error on the insertion, rolls back the transaction; otherwise, commits the transaction
IF @.@.error <> 0 OR @.@.rowcount <> 1
BEGIN
ROLLBACK TRANSACTION
SET @.message = 'Insertion failure on AcctTypeCatalog table.'
RETURN @.message

END
ELSE
BEGIN

COMMIT TRANSACTION
END

RETURN @.@.ROWCOUNT
END
GO

--execute the procedure
DECLARE @.message VARCHAR (40);
EXEC NewAcctTypeSP 'CDs', @.message;
I am not quite sure where I got a type converting error in my code and anyone can help me solve it?
(p.s. I want to return the @.message value to my .aspx page)
Thanks.

You should probably get rid of the RETURN @.@.ROWCOUNT line. It may be getting confused that sometimes you return a varchar and other times int (the rowcount).
Marcie|||Hi Marcie,
I have get rid of the @.@.RowCount, however, I didn't get value from my @.message, it just returned 'undefined'.
do u know why, and how can i fix it?
Thanks.|||Where is it undefined, from your code or still running your test proc?
Marcie|||

when I executed my .aspx page, I input a duplicated value in a field intentionally and since it should return an error message that I have defined in my dtore procedure, however, I just got 'undefined' instead of my error message...
so, here is my .aspx code:
public function SubmitClick (sender:Object, e:EventArgs) : void
{
if (Page.IsValid)
{
myConnection = new SqlConnection(System.Configuration.ConfigurationSettings.AppSettings("ConnectionString"));
var acctTypeDA : SqlDataAdapter = new SqlDataAdapter ("select * from AcctTypeCatalog", myConnection);

acctTypeDA.InsertCommand = new SqlCommand("NewAcctType", myConnection);
acctTypeDA.InsertCommand.CommandType = CommandType.StoredProcedure;
acctTypeDA.InsertCommand.Parameters.Add(new SqlParameter("@.acctType", SqlDbType.VarChar, 20)).Value = accountType.Text;

var myParm : SqlParameter = acctTypeDA.InsertCommand.Parameters.Add("@.message", SqlDbType.VarChar, 40);
myParm.Direction = ParameterDirection.Output;

<%--try to get value from @.message and assign it to the variable --%>
var msg : String = acctTypeDA.InsertCommand.Parameters("@.message").Value;
msgLabel.Text = msg;

BindGrid();

}
else
{
msgLabel.Text = "The Page contains error!"
}
}
my store procedure:
ALTER PROC NewAcctTypeSP
(@.acctType VARCHAR(20), @.message VARCHAR (40) OUT)
AS
BEGIN
--checks if the new account type is already exist
IF EXISTS (SELECT * FROM AcctTypeCatalog WHERE acctType = @.acctType)
BEGIN
SET @.message = 'The account type is already exist'
RETURN
END

BEGIN TRANSACTION
INSERT INTO AcctTypeCatalog (acctType) VALUES (@.acctType)

--if there is an error on the insertion, rolls back the transaction; otherwise, commits the transaction
IF @.@.error <> 0 OR @.@.rowcount <> 1
BEGIN
ROLLBACK TRANSACTION
SET @.message = 'Insertion failure on AcctTypeCatalog table.'
RETURN
END
ELSE
BEGIN
SET @.message = 'Insertion Successful!'
COMMIT TRANSACTION
END
RETURN
END
GO
I have tested my procedure, it works fine in SQL server, however, don't know why I couldn't get the value from @.message on my .aspx page.
Any idea?
Thanks

|||What language is that? You won't be able to get the value of your OUTPUT parameter until right after the command has executed, something like an ExecuteNonQuery line.
Marcie|||hi Marcie,
I used JScript to create my page with using the store procedure. (JScipt is very similar with C#)
I have reviewed the tutorial from the ASP.net and it doesn't have any ExecuteNonQuery statement on the following example:

<script language="JScript" runat="server">
publicfunction GetEmployees_Click(sender : Object, e : EventArgs) :void
{
var myConnection : SqlConnection =new SqlConnection(System.Configuration.ConfigurationSettings.AppSettings("NWString"));
var myCommand : SqlDataAdapter =new SqlDataAdapter("SalesByCategory", myConnection);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
myCommand.SelectCommand.Parameters.Add(new SqlParameter("@.CategoryName", SqlDbType.NVarChar, 15));
myCommand.SelectCommand.Parameters("@.CategoryName").Value = SelectCategory.Value;
myCommand.SelectCommand.Parameters.Add(new SqlParameter("@.OrdYear", SqlDbType.NVarChar, 4));
myCommand.SelectCommand.Parameters("@.OrdYear").Value = SelectYear.Value;
var ds : DataSet =new DataSet();
myCommand.Fill(ds, "Sales");
MyDataGrid.DataSource=ds.Tables("Sales").DefaultView;
MyDataGrid.DataBind();
}
</script>

So, should I use the ExecuteNonQuery statement to get my output parameter? any example you could show me for getting back the output parameter value with using store procedure(it's ok if that's written in VB or C#)?
i have tried to find some material about this problem, but can't get any of it ...
Thanks again.
|||In the example you show here, the Command gets executed in the myCommand.Fill line, your code didn't have anything like that.
Since you have your command object set up as the InsertCommand of a DataAdapter object, I believe your command would automatically fire when the .Update method is called.
Marcie|||The problem is that return parameters in T-SQL arealways integers. That is whay you got the compilation error, and why you are not getting the value you expect in your client-side code.
Even though you have @.message defined as an output parameter, the RETURN @.message is causing you to error out.|||

Thanks pjmcb,
I already got my problem fixed.

Compatiblity level in SQL 2005

What does are the rammifications in SQL 2005 of setting the compatibility level for a database to a lower level, for example SQL 2000 (80)?

Does this affect the underlying datastructure, the stored files on the server, or the indexes?

What effect does changing the compatibility level have? Does changing it cause the server to have to do any work to the indexs or table?

TIA!

refer this link,

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/508c686d-2bd4-41ba-8602-48ebca266659.htm

performance dashboard cannot be used if the compatability is not 90.......

|||

Compatibility level allows you to keep databases in SQL Server 2005 that remain compatible with prior versions of SQL Server. This also means that you cannot use Transact-SQL extensions introduced in SQL Server 2005 with a SQL Server 2000-compatible database. AFAIK there is not much change in storage architecture of sql server 2005 from 2000. Still they are stored in Pages/extents.

Madhu

Tuesday, February 14, 2012

Compatibility level, SQL 2005

In SQL Server 2005 it is possible to set a compatibility level.
Prior to this server we were running SQL 2000. Wil still have one
linked server running SQL 2000.
What I'm about: what does this comp. level actually do? When
is it an advantage - and when not?
Regards /SnedkerMorten Snedker (morten_spammenot_ATdbconsult.dk) writes:
> In SQL Server 2005 it is possible to set a compatibility level.
> Prior to this server we were running SQL 2000. Wil still have one
> linked server running SQL 2000.
> What I'm about : what does this comp. level actually do? When
> is it an advantage - and when not?
Use it only if you have legacy code that does not compile in SQL 2005, and
you don't find it worth the effort to fix the code. (Or you can't, because
it's a 3rd party app.)
I don't remember on the top of my head if there are any run-time differences
between compatibility levels 80 and 90. (There are between 60/65 and the
others.)
Note that if you go with compatibility level 80, there may be new features
that will not be available to you.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Check Books Online for SQL Server 2005, sp_dbcmptlevel. You'll find an elabo
rate explanation about
what these settings do.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Morten Snedker" <morten_spammenot_ATdbconsult.dk> wrote in message
news:qdji82562gpo3ojtlk8oinohdktejkup5r@.
4ax.com...
> In SQL Server 2005 it is possible to set a compatibility level.
> Prior to this server we were running SQL 2000. Wil still have one
> linked server running SQL 2000.
> What I'm about : what does this comp. level actually do? When
> is it an advantage - and when not?
>
> Regards /Snedker|||Erland wrote on Fri, 9 Jun 2006 11:13:55 +0000 (UTC):

> Morten Snedker (morten_spammenot_ATdbconsult.dk) writes:
> Use it only if you have legacy code that does not compile in SQL 2005, and
> you don't find it worth the effort to fix the code. (Or you can't, because
> it's a 3rd party app.)
> I don't remember on the top of my head if there are any run-time
> differences between compatibility levels 80 and 90. (There are between
> 60/65 and the others.)
> Note that if you go with compatibility level 80, there may be new features
> that will not be available to you.
>
And also features like backups - at anything except level 90 you can't back
up your database!
Dan|||Daniel Crichton (msnews@.worldofspack.com) writes:
> And also features like backups - at anything except level 90 you can't
> back up your database!
What? Where did you get that from?
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||> And also features like backups - at anything except level 90 you can't bac
k up your database!
That would have been a disaster. Backup work find, I just tried below on my
2005 sp2 instance:
exec sp_dbcmptlevel 'pubs', 80
BACKUP DATABASE pubs TO DISK = 'C:\pubs.bak'
Perhaps there is a problem win some of the tools if db compat level is lower
? Like SSMS or Maint
plans?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Daniel Crichton" <msnews@.worldofspack.com> wrote in message
news:e2nNjE9iGHA.1640@.TK2MSFTNGP02.phx.gbl...
> Erland wrote on Fri, 9 Jun 2006 11:13:55 +0000 (UTC):
>
>
> And also features like backups - at anything except level 90 you can't bac
k up your database!
> Dan
>|||Tibor wrote on Fri, 9 Jun 2006 17:01:59 +0200:

> That would have been a disaster. Backup work find, I just tried below on
> my 2005 sp2 instance:
> exec sp_dbcmptlevel 'pubs', 80
> BACKUP DATABASE pubs TO DISK = 'C:\pubs.bak'
> Perhaps there is a problem win some of the tools if db compat level is
> lower? Like SSMS or Maint plans?
Ah, yeah, that was it - SSMS won't allow a maintenance plan for a compat
level 80 db, it doesn't show them in the list of available databases to be
backed up.
Dan|||Erland wrote on Fri, 9 Jun 2006 14:59:51 +0000 (UTC):

> Daniel Crichton (msnews@.worldofspack.com) writes:
> What? Where did you get that from?
>
I restored a 2000 db to 2005, it was compatibility 80, I couldn't run
BACKUP. I switched it to 90, BACKUP runs fine.
Dan|||Daniel wrote to Erland Sommarskog on Mon, 12 Jun 2006 08:36:36 +0100:

> Erland wrote on Fri, 9 Jun 2006 14:59:51 +0000 (UTC):
>
> I restored a 2000 db to 2005, it was compatibility 80, I couldn't run
> BACKUP. I switched it to 90, BACKUP runs fine.
As I replied to Tibor, it was the maintenance wiz in SMSS that won't see the
databases at compatibility 80, not BACKUP itself. Sorry, my memory was a
little hazy on this one.
Dan

Compatibility level SQL Server 2000 (80) on SQL Server 2005.

Hi,
Does anyone know that after SQL Server 2000 database migrating to SQL Server
2005 server, if the compatibility level still setting on SQL Server 2000
(80), will affect database performance (such insert, update, delete, etc.)?
If I need change SQL Server 2000 (80) level to SQL Server 2005 (90) in
Database Properties for 500 GB database, how long it will take?
Regards!
-Chen"Chen" <Chen@.discussions.microsoft.com> wrote in message
news:0BF2F1FC-AA1E-4D61-B190-9F06596B3962@.microsoft.com...
> Hi,
> Does anyone know that after SQL Server 2000 database migrating to SQL
> Server
> 2005 server, if the compatibility level still setting on SQL Server 2000
> (80), will affect database performance (such insert, update, delete,
> etc.)?
>
Not really, but you can't use many new features until you switch. Since
upgrading requires testing, and changing compatibility level requires
testing, It's better if you change the compatibility level immediately and
get all your testing over with at once.
Only run in 80 compatibility mode if you identify a problem with your
database running in 90 mode that you need more time to fix.
> If I need change SQL Server 2000 (80) level to SQL Server 2005 (90) in
> Database Properties for 500 GB database, how long it will take?
>
It doesn't change the data, so it shouldn't take long.
David

Compatibility level SQL Server 2000 (80) on SQL Server 2005.

Hi,
Does anyone know that after SQL Server 2000 database migrating to SQL Server
2005 server, if the compatibility level still setting on SQL Server 2000
(80), will affect database performance (such insert, update, delete, etc.)?
If I need change SQL Server 2000 (80) level to SQL Server 2005 (90) in
Database Properties for 500 GB database, how long it will take?
Regards!
-Chen
"Chen" <Chen@.discussions.microsoft.com> wrote in message
news:0BF2F1FC-AA1E-4D61-B190-9F06596B3962@.microsoft.com...
> Hi,
> Does anyone know that after SQL Server 2000 database migrating to SQL
> Server
> 2005 server, if the compatibility level still setting on SQL Server 2000
> (80), will affect database performance (such insert, update, delete,
> etc.)?
>
Not really, but you can't use many new features until you switch. Since
upgrading requires testing, and changing compatibility level requires
testing, It's better if you change the compatibility level immediately and
get all your testing over with at once.
Only run in 80 compatibility mode if you identify a problem with your
database running in 90 mode that you need more time to fix.

> If I need change SQL Server 2000 (80) level to SQL Server 2005 (90) in
> Database Properties for 500 GB database, how long it will take?
>
It doesn't change the data, so it shouldn't take long.
David

Compatibility level SQL Server 2000 (80) on SQL Server 2005.

Hi,
Does anyone know that after SQL Server 2000 database migrating to SQL Server
2005 server, if the compatibility level still setting on SQL Server 2000
(80), will affect database performance (such insert, update, delete, etc.)?
If I need change SQL Server 2000 (80) level to SQL Server 2005 (90) in
Database Properties for 500 GB database, how long it will take?
Regards!
-Chen"Chen" <Chen@.discussions.microsoft.com> wrote in message
news:0BF2F1FC-AA1E-4D61-B190-9F06596B3962@.microsoft.com...
> Hi,
> Does anyone know that after SQL Server 2000 database migrating to SQL
> Server
> 2005 server, if the compatibility level still setting on SQL Server 2000
> (80), will affect database performance (such insert, update, delete,
> etc.)?
>
Not really, but you can't use many new features until you switch. Since
upgrading requires testing, and changing compatibility level requires
testing, It's better if you change the compatibility level immediately and
get all your testing over with at once.
Only run in 80 compatibility mode if you identify a problem with your
database running in 90 mode that you need more time to fix.

> If I need change SQL Server 2000 (80) level to SQL Server 2005 (90) in
> Database Properties for 500 GB database, how long it will take?
>
It doesn't change the data, so it shouldn't take long.
David

Compatibility Level SQL Server 2000 (80)

Hallo Everyone,

I have an SQL database that I need to detach from an SQL2005 server and reattach to an SQL 2000 database. I tried to set the Compatibility level from SQL Server 2005 (90) to SQL Server 2000 (80). This did not work

Any ideas?

Nigel...

How are you trying to do this? Try setting the compat level to 80 when attached to SQL Server 2005, and then attach to SQL Server 2000.

Peter

|||

Hallo Peter,

This is what I did

1. Goto SQL 2005
2. Set the compatability level from 90 to 80
3. Detach the database from SQL 2005
4. Goto SQL 2000
5. Attach the database

Unfortunately this does not work, any ideas?

Thanks..

Nigel...

|||

Can you be more specific on what does not work (i.e how are you checking or verifying it is not working)?

Thanks,

Pete

|||I have

the same problem. You get an error (don't have it at hand) telling you

to repair the database (index problem). As far as I have been able to find out about

this matter, it is not possible to go back to SQL Server 2000 once you

have attached the database to a SQL Server 2005. You can create a new,

empty database and transfer the data afterwards. So the question is: is

it at all possible to work with a database under SQL Server 2005 and

easily transfer that to SQL Server 2000?

Thanks for any help on this. If there is no solution, I will have to go back to a SQL Server 2000.|||

Sorry, I may have misled you. It is not possible to move a database from SQL Server 2005 to SQL Server 2000 through attach/detach and backup/restore as SQL Server 2000 does know the structure of the database.

Compatibility mode was introduced back in SQL 7 or earlier to keep applications running after upgrading the database to the latest version. Compatibility mode is all about how T-SQL is parsed and interpreted. Compatibility mode does not change the structure of the database.

Why are you looking to move a database from SQL Server 2005 to SQL Server 2000?

Here are some options for you to consider (there could be more)

* You can script and transfer the data using SMO (or Copy Database Wizard)

* You can replicate the data from SQL Server 2005 to SQL Server 2000

* You can keep the databases in SQL Server 2000 and continue to use the SQL Server 2005 tools.

* Keep the database in SQL Server 2005 with database compatibility mode at 8 so other applications can continue to access the database.

Thanks,

Peter

|||Thanks. That was exactly my impression. I think this

* You can keep the databases in SQL Server 2000 and continue to use the SQL Server 2005 tools.

is what I will do.

Thanks!
Patrick
|||

Thanks Peter,

I appriciate it...

Nigel...

|||

Hi Peter,

I have a situation where I'm running a piece of software on SQL2005 and I need to give a backup of the sql database for that software to someone who is running SQL2000, is there any way that I can take a backup, or basically get them to be able to read this database on their SQL2000 setup?

Currently when they try to restore a backup I've taken they get an SQL Server error saying: The backed up databas has on-disk structure version 611. The server supports 539 and cannot restore or upgrade this database.

Any help much appreciated.

Thanks, Mark.

|||

You can not backup on SQL2005 and restore on SQL2000. However you have other options:

* Script the database from SQL2005 to SQL2000

* Use the full version of SQL Server 2005, install as separate instance

* Use the free SQL Server 2005 Express edition, install as separate instance

* Creating a linked server from SQL2000 to SQL2005 should work

Thanks,

Peter

|||

Hi Peter,

Could you please help me how to figure out my problem:

I have a database upgraded from SQL 2000 to SQL 2005. Some of the store procedures, functions, triggers do not run in 90 mode. How can I get all the name of these store procs/functions/triggers so that I can manually modify them in order to make it work in my existed application? Do you know any way that make this job faster and lighter?

Thanks,

CCC

Compatibility Level SQL Server 2000 (80)

Hallo Everyone,

I have an SQL database that I need to detach from an SQL2005 server and reattach to an SQL 2000 database. I tried to set the Compatibility level from SQL Server 2005 (90) to SQL Server 2000 (80). This did not work

Any ideas?

Nigel...

How are you trying to do this? Try setting the compat level to 80 when attached to SQL Server 2005, and then attach to SQL Server 2000.

Peter

|||

Hallo Peter,

This is what I did

1. Goto SQL 2005
2. Set the compatability level from 90 to 80
3. Detach the database from SQL 2005
4. Goto SQL 2000
5. Attach the database

Unfortunately this does not work, any ideas?

Thanks..

Nigel...

|||

Can you be more specific on what does not work (i.e how are you checking or verifying it is not working)?

Thanks,

Pete

|||I have

the same problem. You get an error (don't have it at hand) telling you

to repair the database (index problem). As far as I have been able to find out about

this matter, it is not possible to go back to SQL Server 2000 once you

have attached the database to a SQL Server 2005. You can create a new,

empty database and transfer the data afterwards. So the question is: is

it at all possible to work with a database under SQL Server 2005 and

easily transfer that to SQL Server 2000?

Thanks for any help on this. If there is no solution, I will have to go back to a SQL Server 2000.|||

Sorry, I may have misled you. It is not possible to move a database from SQL Server 2005 to SQL Server 2000 through attach/detach and backup/restore as SQL Server 2000 does know the structure of the database.

Compatibility mode was introduced back in SQL 7 or earlier to keep applications running after upgrading the database to the latest version. Compatibility mode is all about how T-SQL is parsed and interpreted. Compatibility mode does not change the structure of the database.

Why are you looking to move a database from SQL Server 2005 to SQL Server 2000?

Here are some options for you to consider (there could be more)

* You can script and transfer the data using SMO (or Copy Database Wizard)

* You can replicate the data from SQL Server 2005 to SQL Server 2000

* You can keep the databases in SQL Server 2000 and continue to use the SQL Server 2005 tools.

* Keep the database in SQL Server 2005 with database compatibility mode at 8 so other applications can continue to access the database.

Thanks,

Peter

|||Thanks. That was exactly my impression. I think this

* You can keep the databases in SQL Server 2000 and continue to use the SQL Server 2005 tools.

is what I will do.

Thanks!
Patrick
|||

Thanks Peter,

I appriciate it...

Nigel...

|||

Hi Peter,

I have a situation where I'm running a piece of software on SQL2005 and I need to give a backup of the sql database for that software to someone who is running SQL2000, is there any way that I can take a backup, or basically get them to be able to read this database on their SQL2000 setup?

Currently when they try to restore a backup I've taken they get an SQL Server error saying: The backed up databas has on-disk structure version 611. The server supports 539 and cannot restore or upgrade this database.

Any help much appreciated.

Thanks, Mark.

|||

You can not backup on SQL2005 and restore on SQL2000. However you have other options:

* Script the database from SQL2005 to SQL2000

* Use the full version of SQL Server 2005, install as separate instance

* Use the free SQL Server 2005 Express edition, install as separate instance

* Creating a linked server from SQL2000 to SQL2005 should work

Thanks,

Peter

|||

Hi Peter,

Could you please help me how to figure out my problem:

I have a database upgraded from SQL 2000 to SQL 2005. Some of the store procedures, functions, triggers do not run in 90 mode. How can I get all the name of these store procs/functions/triggers so that I can manually modify them in order to make it work in my existed application? Do you know any way that make this job faster and lighter?

Thanks,

CCC

Compatibility Level SQL Server 2000 (80)

Hallo Everyone,

I have an SQL database that I need to detach from an SQL2005 server and reattach to an SQL 2000 database. I tried to set the Compatibility level from SQL Server 2005 (90) to SQL Server 2000 (80). This did not work

Any ideas?

Nigel...

How are you trying to do this? Try setting the compat level to 80 when attached to SQL Server 2005, and then attach to SQL Server 2000.

Peter

|||

Hallo Peter,

This is what I did

1. Goto SQL 2005
2. Set the compatability level from 90 to 80
3. Detach the database from SQL 2005
4. Goto SQL 2000
5. Attach the database

Unfortunately this does not work, any ideas?

Thanks..

Nigel...

|||

Can you be more specific on what does not work (i.e how are you checking or verifying it is not working)?

Thanks,

Pete

|||I have

the same problem. You get an error (don't have it at hand) telling you

to repair the database (index problem). As far as I have been able to find out about

this matter, it is not possible to go back to SQL Server 2000 once you

have attached the database to a SQL Server 2005. You can create a new,

empty database and transfer the data afterwards. So the question is: is

it at all possible to work with a database under SQL Server 2005 and

easily transfer that to SQL Server 2000?

Thanks for any help on this. If there is no solution, I will have to go back to a SQL Server 2000.|||

Sorry, I may have misled you. It is not possible to move a database from SQL Server 2005 to SQL Server 2000 through attach/detach and backup/restore as SQL Server 2000 does know the structure of the database.

Compatibility mode was introduced back in SQL 7 or earlier to keep applications running after upgrading the database to the latest version. Compatibility mode is all about how T-SQL is parsed and interpreted. Compatibility mode does not change the structure of the database.

Why are you looking to move a database from SQL Server 2005 to SQL Server 2000?

Here are some options for you to consider (there could be more)

* You can script and transfer the data using SMO (or Copy Database Wizard)

* You can replicate the data from SQL Server 2005 to SQL Server 2000

* You can keep the databases in SQL Server 2000 and continue to use the SQL Server 2005 tools.

* Keep the database in SQL Server 2005 with database compatibility mode at 8 so other applications can continue to access the database.

Thanks,

Peter

|||Thanks. That was exactly my impression. I think this

* You can keep the databases in SQL Server 2000 and continue to use the SQL Server 2005 tools.

is what I will do.

Thanks!
Patrick
|||

Thanks Peter,

I appriciate it...

Nigel...

|||

Hi Peter,

I have a situation where I'm running a piece of software on SQL2005 and I need to give a backup of the sql database for that software to someone who is running SQL2000, is there any way that I can take a backup, or basically get them to be able to read this database on their SQL2000 setup?

Currently when they try to restore a backup I've taken they get an SQL Server error saying: The backed up databas has on-disk structure version 611. The server supports 539 and cannot restore or upgrade this database.

Any help much appreciated.

Thanks, Mark.

|||

You can not backup on SQL2005 and restore on SQL2000. However you have other options:

* Script the database from SQL2005 to SQL2000

* Use the full version of SQL Server 2005, install as separate instance

* Use the free SQL Server 2005 Express edition, install as separate instance

* Creating a linked server from SQL2000 to SQL2005 should work

Thanks,

Peter

|||

Hi Peter,

Could you please help me how to figure out my problem:

I have a database upgraded from SQL 2000 to SQL 2005. Some of the store procedures, functions, triggers do not run in 90 mode. How can I get all the name of these store procs/functions/triggers so that I can manually modify them in order to make it work in my existed application? Do you know any way that make this job faster and lighter?

Thanks,

CCC

Compatibility Level Question

I am a little confused on the importance of the Compatability Level setting.
I have a database originally created in SQL Server 2000 that I backed up and
then restored to SQL Server 2005. The compatibility level is currently set
at 80 (SQL 2000). I would like to change this to 90 (SQL 2005) but am not
sure of the ramifications of doing this. Can someone tell me of any negative
issues I should be aware of by doing this? I would like to treat this
database as if it were created as a SQL 2005 database (IOW, I don't need any
2000 support or compatibility).
Amos.Check out the description of sp_dbcmptlevel in the SQL 2005 Books Online for
a description of the behavior differences between 80 and 90. If you see not
changes that affect your app, you are probably ok but it's always a good
idea to test.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Amos Soma" <amos_j_soma@.yahoo.com> wrote in message
news:up7T4sgEGHA.2648@.TK2MSFTNGP11.phx.gbl...
>I am a little confused on the importance of the Compatability Level
>setting. I have a database originally created in SQL Server 2000 that I
>backed up and then restored to SQL Server 2005. The compatibility level is
>currently set at 80 (SQL 2000). I would like to change this to 90 (SQL
>2005) but am not sure of the ramifications of doing this. Can someone tell
>me of any negative issues I should be aware of by doing this? I would like
>to treat this database as if it were created as a SQL 2005 database (IOW, I
>don't need any 2000 support or compatibility).
> Amos.
>

Compatibility Level Question

I am a little confused on the importance of the Compatability Level setting.
I have a database originally created in SQL Server 2000 that I backed up and
then restored to SQL Server 2005. The compatibility level is currently set
at 80 (SQL 2000). I would like to change this to 90 (SQL 2005) but am not
sure of the ramifications of doing this. Can someone tell me of any negative
issues I should be aware of by doing this? I would like to treat this
database as if it were created as a SQL 2005 database (IOW, I don't need any
2000 support or compatibility).
Amos.
Check out the description of sp_dbcmptlevel in the SQL 2005 Books Online for
a description of the behavior differences between 80 and 90. If you see not
changes that affect your app, you are probably ok but it's always a good
idea to test.
Hope this helps.
Dan Guzman
SQL Server MVP
"Amos Soma" <amos_j_soma@.yahoo.com> wrote in message
news:up7T4sgEGHA.2648@.TK2MSFTNGP11.phx.gbl...
>I am a little confused on the importance of the Compatability Level
>setting. I have a database originally created in SQL Server 2000 that I
>backed up and then restored to SQL Server 2005. The compatibility level is
>currently set at 80 (SQL 2000). I would like to change this to 90 (SQL
>2005) but am not sure of the ramifications of doing this. Can someone tell
>me of any negative issues I should be aware of by doing this? I would like
>to treat this database as if it were created as a SQL 2005 database (IOW, I
>don't need any 2000 support or compatibility).
> Amos.
>

Compatibility Level Question

I am a little confused on the importance of the Compatability Level setting.
I have a database originally created in SQL Server 2000 that I backed up and
then restored to SQL Server 2005. The compatibility level is currently set
at 80 (SQL 2000). I would like to change this to 90 (SQL 2005) but am not
sure of the ramifications of doing this. Can someone tell me of any negative
issues I should be aware of by doing this? I would like to treat this
database as if it were created as a SQL 2005 database (IOW, I don't need any
2000 support or compatibility).
Amos.Check out the description of sp_dbcmptlevel in the SQL 2005 Books Online for
a description of the behavior differences between 80 and 90. If you see not
changes that affect your app, you are probably ok but it's always a good
idea to test.
Hope this helps.
Dan Guzman
SQL Server MVP
"Amos Soma" <amos_j_soma@.yahoo.com> wrote in message
news:up7T4sgEGHA.2648@.TK2MSFTNGP11.phx.gbl...
>I am a little confused on the importance of the Compatability Level
>setting. I have a database originally created in SQL Server 2000 that I
>backed up and then restored to SQL Server 2005. The compatibility level is
>currently set at 80 (SQL 2000). I would like to change this to 90 (SQL
>2005) but am not sure of the ramifications of doing this. Can someone tell
>me of any negative issues I should be aware of by doing this? I would like
>to treat this database as if it were created as a SQL 2005 database (IOW, I
>don't need any 2000 support or compatibility).
> Amos.
>

Compatibility level bug?

I think found a bug in SQL Server 2005 with respect to the database
compatibility level.
Scenario:
2 DBs on the same SQL Server 2005:
- fbSunshore
- swSunshore
Both DBs with compatibility level set to SQL Server 2005
Both DBs have a table 'Steuerschluessel'
Test 1:
Run the following statements:
USE swSunshore
UPDATE Steuerschluessel SET Info = '?'
Result: NO problem!!
Test 2:
Run the following statements:
USE swSunshore
UPDATE Steuerschluessel SET Info = '?'
FROM Steuerschluessel AS ThisTable
INNER JOIN fbSunshore..Steuerschluessel
ON ThisTable.Steuerschluessel
= fbSunshore..Steuerschluessel.Steuerschluessel
Result: 'Invalid columns name: 'info':
Test 3:
Set the compatibility level of swSunshore to SQL Server 2000
an rerun the statements from Test2
USE swSunshore
UPDATE Steuerschluessel SET Info = '?'
FROM Steuerschluessel AS ThisTable
INNER JOIN fbSunshore..Steuerschluessel
ON ThisTable.Steuerschluessel
= fbSunshore..Steuerschluessel.Steuerschluessel
Result: NO problem
AFAIK info is not a reserved word in SQL Server 2005, so I can not find a
reason for this behavior.
Any idea?
Bernd Beekes
have you tried this
USE swSunshore
UPDATE ThisTable.Steuerschluessel SET ThisTable.Info = '?'
FROM Steuerschluessel AS ThisTable
INNER JOIN fbSunshore..Steuerschluessel
ON ThisTable.Steuerschluessel
= fbSunshore..Steuerschluessel.Steuerschluessel
"BerndB" <BerndB@.discussions.microsoft.com> wrote in message
news:B9B02693-E908-4CD2-B9C7-E115A5F268EE@.microsoft.com...
> I think found a bug in SQL Server 2005 with respect to the database
> compatibility level.
> Scenario:
> 2 DBs on the same SQL Server 2005:
> - fbSunshore
> - swSunshore
> Both DBs with compatibility level set to SQL Server 2005
> Both DBs have a table 'Steuerschluessel'
> Test 1:
> Run the following statements:
> USE swSunshore
> UPDATE Steuerschluessel SET Info = '?'
> Result: NO problem!!
> Test 2:
> Run the following statements:
> USE swSunshore
> UPDATE Steuerschluessel SET Info = '?'
> FROM Steuerschluessel AS ThisTable
> INNER JOIN fbSunshore..Steuerschluessel
> ON ThisTable.Steuerschluessel
> = fbSunshore..Steuerschluessel.Steuerschluessel
> Result: 'Invalid columns name: 'info':
> Test 3:
> Set the compatibility level of swSunshore to SQL Server 2000
> an rerun the statements from Test2
> USE swSunshore
> UPDATE Steuerschluessel SET Info = '?'
> FROM Steuerschluessel AS ThisTable
> INNER JOIN fbSunshore..Steuerschluessel
> ON ThisTable.Steuerschluessel
> = fbSunshore..Steuerschluessel.Steuerschluessel
> Result: NO problem
> AFAIK info is not a reserved word in SQL Server 2005, so I can not find a
> reason for this behavior.
> Any idea?
> --
> Bernd Beekes
|||Thank You! it works!
Ihad to introduce the 'ThisTable' alias after upgrading to SQL Server 2005
(i. e. in SQL 2000 everything was OK w/o that alias). So there is at least
some logic in this ...
Bernd Beekes
"tolgay" wrote:
...

Compatibility level bug?

I think found a bug in SQL Server 2005 with respect to the database
compatibility level.
Scenario:
2 DBs on the same SQL Server 2005:
- fbSunshore
- swSunshore
Both DBs with compatibility level set to SQL Server 2005
Both DBs have a table 'Steuerschluessel'
Test 1:
Run the following statements:
USE swSunshore
UPDATE Steuerschluessel SET Info = '?'
Result: NO problem!!
Test 2:
Run the following statements:
USE swSunshore
UPDATE Steuerschluessel SET Info = '?'
FROM Steuerschluessel AS ThisTable
INNER JOIN fbSunshore..Steuerschluessel
ON ThisTable.Steuerschluessel
= fbSunshore..Steuerschluessel.Steuerschluessel
Result: 'Invalid columns name: 'info':
Test 3:
Set the compatibility level of swSunshore to SQL Server 2000
an rerun the statements from Test2
USE swSunshore
UPDATE Steuerschluessel SET Info = '?'
FROM Steuerschluessel AS ThisTable
INNER JOIN fbSunshore..Steuerschluessel
ON ThisTable.Steuerschluessel
= fbSunshore..Steuerschluessel.Steuerschluessel
Result: NO problem
AFAIK info is not a reserved word in SQL Server 2005, so I can not find a
reason for this behavior.
Any idea?
Bernd Beekeshave you tried this
USE swSunshore
UPDATE ThisTable.Steuerschluessel SET ThisTable.Info = '?'
FROM Steuerschluessel AS ThisTable
INNER JOIN fbSunshore..Steuerschluessel
ON ThisTable.Steuerschluessel
= fbSunshore..Steuerschluessel.Steuerschluessel
"BerndB" <BerndB@.discussions.microsoft.com> wrote in message
news:B9B02693-E908-4CD2-B9C7-E115A5F268EE@.microsoft.com...
> I think found a bug in SQL Server 2005 with respect to the database
> compatibility level.
> Scenario:
> 2 DBs on the same SQL Server 2005:
> - fbSunshore
> - swSunshore
> Both DBs with compatibility level set to SQL Server 2005
> Both DBs have a table 'Steuerschluessel'
> Test 1:
> Run the following statements:
> USE swSunshore
> UPDATE Steuerschluessel SET Info = '?'
> Result: NO problem!!
> Test 2:
> Run the following statements:
> USE swSunshore
> UPDATE Steuerschluessel SET Info = '?'
> FROM Steuerschluessel AS ThisTable
> INNER JOIN fbSunshore..Steuerschluessel
> ON ThisTable.Steuerschluessel
> = fbSunshore..Steuerschluessel.Steuerschluessel
> Result: 'Invalid columns name: 'info':
> Test 3:
> Set the compatibility level of swSunshore to SQL Server 2000
> an rerun the statements from Test2
> USE swSunshore
> UPDATE Steuerschluessel SET Info = '?'
> FROM Steuerschluessel AS ThisTable
> INNER JOIN fbSunshore..Steuerschluessel
> ON ThisTable.Steuerschluessel
> = fbSunshore..Steuerschluessel.Steuerschluessel
> Result: NO problem
> AFAIK info is not a reserved word in SQL Server 2005, so I can not find a
> reason for this behavior.
> Any idea?
> --
> Bernd Beekes|||Thank You! it works!
Ihad to introduce the 'ThisTable' alias after upgrading to SQL Server 2005
(i. e. in SQL 2000 everything was OK w/o that alias). So there is at least
some logic in this ...
Bernd Beekes
"tolgay" wrote:
...

compatibility level 80 in sql server 2005

Hi,
I have a general question about the implications of setting sql server 2005
database to compatibility level 80. It will take me some time to convert and
test the existing db schema and app to fully support sql 2005, so for now I
use this compatibility feature.
Besides not being able to use the new features of sql 2005 will setting to
compatibility level 80 effect negatively the db response time, performance,
etc...?
And if there are no problems with that temporary solution does anybody know
about any resources or articles on the web that I could provide to my
clients who are concerned about setting the compatibility level to 80?
Thank you,
VadimThere are some features in 2005 you won't be able to take advantage of but
for the most part it should not affect performance. But my question is why
are you at 80? Did you try it at 90 and have issues? Did you run the
Upgrade Advisor against your 2000 db and traces to see what issues you have
if any?
--
Andrew J. Kelly SQL MVP
"Vadim" <vadim@.dontsend.com> wrote in message
news:%23qPp0BniGHA.4716@.TK2MSFTNGP03.phx.gbl...
> Hi,
> I have a general question about the implications of setting sql server
> 2005 database to compatibility level 80. It will take me some time to
> convert and test the existing db schema and app to fully support sql 2005,
> so for now I use this compatibility feature.
> Besides not being able to use the new features of sql 2005 will setting to
> compatibility level 80 effect negatively the db response time,
> performance, etc...?
> And if there are no problems with that temporary solution does anybody
> know about any resources or articles on the web that I could provide to my
> clients who are concerned about setting the compatibility level to 80?
> Thank you,
> Vadim
>|||Andrew J. Kelly wrote:
> There are some features in 2005 you won't be able to take advantage of but
> for the most part it should not affect performance. But my question is why
> are you at 80? Did you try it at 90 and have issues? Did you run the
> Upgrade Advisor against your 2000 db and traces to see what issues you have
> if any?
> --
> Andrew J. Kelly SQL MVP
>
> "Vadim" <vadim@.dontsend.com> wrote in message
> news:%23qPp0BniGHA.4716@.TK2MSFTNGP03.phx.gbl...
> > Hi,
> > I have a general question about the implications of setting sql server
> > 2005 database to compatibility level 80. It will take me some time to
> > convert and test the existing db schema and app to fully support sql 2005,
> > so for now I use this compatibility feature.
> > Besides not being able to use the new features of sql 2005 will setting to
> > compatibility level 80 effect negatively the db response time,
> > performance, etc...?
> > And if there are no problems with that temporary solution does anybody
> > know about any resources or articles on the web that I could provide to my
> > clients who are concerned about setting the compatibility level to 80?
> >
> > Thank you,
> >
> > Vadim
> >
For backward compatibility details look into in BOL
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/instsql9/html/4760732b-aa3c-4f07-96ec-ba920476dd69.htm
Regards
Amish Shah|||Hi Andrew,
Yes, the main and I think only problem is sql syntax for linking tables for
inner and outer joins, I currently syntax compatible with Oracle and Sql
Server 7/2000, Microsoft just discontinued support for that syntax so I'll
have to chnage and test the whole app to make sure it works properly and it
takes time.
Thank you for your reply,
Vadim
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eXcp8MqiGHA.3496@.TK2MSFTNGP02.phx.gbl...
> There are some features in 2005 you won't be able to take advantage of but
> for the most part it should not affect performance. But my question is why
> are you at 80? Did you try it at 90 and have issues? Did you run the
> Upgrade Advisor against your 2000 db and traces to see what issues you
> have if any?
> --
> Andrew J. Kelly SQL MVP
>
> "Vadim" <vadim@.dontsend.com> wrote in message
> news:%23qPp0BniGHA.4716@.TK2MSFTNGP03.phx.gbl...
>> Hi,
>> I have a general question about the implications of setting sql server
>> 2005 database to compatibility level 80. It will take me some time to
>> convert and test the existing db schema and app to fully support sql
>> 2005, so for now I use this compatibility feature.
>> Besides not being able to use the new features of sql 2005 will setting
>> to compatibility level 80 effect negatively the db response time,
>> performance, etc...?
>> And if there are no problems with that temporary solution does anybody
>> know about any resources or articles on the web that I could provide to
>> my clients who are concerned about setting the compatibility level to 80?
>> Thank you,
>> Vadim
>|||Thank you, Amish, good info but they don't mention how this affects the
performance internally, although based on the previous post it seems like
there are no performance issues.
I'll try also to run the upgrade advisor.
Vadim
"amish" <shahamishm@.gmail.com> wrote in message
news:1149742077.528427.325660@.u72g2000cwu.googlegroups.com...
> Andrew J. Kelly wrote:
>> There are some features in 2005 you won't be able to take advantage of
>> but
>> for the most part it should not affect performance. But my question is
>> why
>> are you at 80? Did you try it at 90 and have issues? Did you run the
>> Upgrade Advisor against your 2000 db and traces to see what issues you
>> have
>> if any?
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Vadim" <vadim@.dontsend.com> wrote in message
>> news:%23qPp0BniGHA.4716@.TK2MSFTNGP03.phx.gbl...
>> > Hi,
>> > I have a general question about the implications of setting sql server
>> > 2005 database to compatibility level 80. It will take me some time to
>> > convert and test the existing db schema and app to fully support sql
>> > 2005,
>> > so for now I use this compatibility feature.
>> > Besides not being able to use the new features of sql 2005 will setting
>> > to
>> > compatibility level 80 effect negatively the db response time,
>> > performance, etc...?
>> > And if there are no problems with that temporary solution does anybody
>> > know about any resources or articles on the web that I could provide to
>> > my
>> > clients who are concerned about setting the compatibility level to 80?
>> >
>> > Thank you,
>> >
>> > Vadim
>> >
> For backward compatibility details look into in BOL
> ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/instsql9/html/4760732b-aa3c-4f07-96ec-ba920476dd69.htm
> Regards
> Amish Shah
>

compatibility level 80 in sql server 2005

Hi,
I have a general question about the implications of setting sql server 2005
database to compatibility level 80. It will take me some time to convert and
test the existing db schema and app to fully support sql 2005, so for now I
use this compatibility feature.
Besides not being able to use the new features of sql 2005 will setting to
compatibility level 80 effect negatively the db response time, performance,
etc...?
And if there are no problems with that temporary solution does anybody know
about any resources or articles on the web that I could provide to my
clients who are concerned about setting the compatibility level to 80?
Thank you,
VadimThere are some features in 2005 you won't be able to take advantage of but
for the most part it should not affect performance. But my question is why
are you at 80? Did you try it at 90 and have issues? Did you run the
Upgrade Advisor against your 2000 db and traces to see what issues you have
if any?
Andrew J. Kelly SQL MVP
"Vadim" <vadim@.dontsend.com> wrote in message
news:%23qPp0BniGHA.4716@.TK2MSFTNGP03.phx.gbl...
> Hi,
> I have a general question about the implications of setting sql server
> 2005 database to compatibility level 80. It will take me some time to
> convert and test the existing db schema and app to fully support sql 2005,
> so for now I use this compatibility feature.
> Besides not being able to use the new features of sql 2005 will setting to
> compatibility level 80 effect negatively the db response time,
> performance, etc...?
> And if there are no problems with that temporary solution does anybody
> know about any resources or articles on the web that I could provide to my
> clients who are concerned about setting the compatibility level to 80?
> Thank you,
> Vadim
>|||Andrew J. Kelly wrote:
[vbcol=seagreen]
> There are some features in 2005 you won't be able to take advantage of but
> for the most part it should not affect performance. But my question is why
> are you at 80? Did you try it at 90 and have issues? Did you run the
> Upgrade Advisor against your 2000 db and traces to see what issues you hav
e
> if any?
> --
> Andrew J. Kelly SQL MVP
>
> "Vadim" <vadim@.dontsend.com> wrote in message
> news:%23qPp0BniGHA.4716@.TK2MSFTNGP03.phx.gbl...
For backward compatibility details look into in BOL
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/instsql9/html/4760732b-aa3c-4f07-96ec-
ba920476dd69.htm
Regards
Amish Shah|||Hi Andrew,
Yes, the main and I think only problem is sql syntax for linking tables for
inner and outer joins, I currently syntax compatible with Oracle and Sql
Server 7/2000, Microsoft just discontinued support for that syntax so I'll
have to chnage and test the whole app to make sure it works properly and it
takes time.
Thank you for your reply,
Vadim
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eXcp8MqiGHA.3496@.TK2MSFTNGP02.phx.gbl...
> There are some features in 2005 you won't be able to take advantage of but
> for the most part it should not affect performance. But my question is why
> are you at 80? Did you try it at 90 and have issues? Did you run the
> Upgrade Advisor against your 2000 db and traces to see what issues you
> have if any?
> --
> Andrew J. Kelly SQL MVP
>
> "Vadim" <vadim@.dontsend.com> wrote in message
> news:%23qPp0BniGHA.4716@.TK2MSFTNGP03.phx.gbl...
>|||Thank you, Amish, good info but they don't mention how this affects the
performance internally, although based on the previous post it seems like
there are no performance issues.
I'll try also to run the upgrade advisor.
Vadim
"amish" <shahamishm@.gmail.com> wrote in message
news:1149742077.528427.325660@.u72g2000cwu.googlegroups.com...
> Andrew J. Kelly wrote:
>
> For backward compatibility details look into in BOL
> ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/instsql9/html/4760732b-aa3c-4f07-96e
c-ba920476dd69.htm
> Regards
> Amish Shah
>

Compatibility level ?

Are there any downsides to changing it from 80 to 90 for a given database ?
Hi Rob
It depends...
Does your database have any objects with names that are now reserved
keywords in compatibility level 90?
EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE
Does any of your code use the *= or =* syntax for outer joins?
Does any of your code update a view that was defined WITH NOCHECK that
includes a TOP?
If your database includes any constructs that is allowed in 80 compatibility
but is not allowed in 90, then you will have problems. Otherwise, you won't.
You can find the full list in the Books Online if you look up
sp_dbcmptlevel.
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://sqlblog.com
"Rob" <robc1@.yahoo.com> wrote in message
news:HoudnQA8uN6nwNXbnZ2dnUVZ_vGinZ2d@.comcast.com. ..
> Are there any downsides to changing it from 80 to 90 for a given database
> ?
>
|||Hi Kalen,
Correct me if I'm wrong, because this is how I explain compatibility level
when teaching or presenting: the compatibility only tells the query engine
how to interpret TSQL code. Thus, at 80 no new features will work, nor syntax
changes in 90.
I'm not missing something, am I?
"Kalen Delaney" wrote:

> Hi Rob
> It depends...
> Does your database have any objects with names that are now reserved
> keywords in compatibility level 90?
> EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE
> Does any of your code use the *= or =* syntax for outer joins?
> Does any of your code update a view that was defined WITH NOCHECK that
> includes a TOP?
> If your database includes any constructs that is allowed in 80 compatibility
> but is not allowed in 90, then you will have problems. Otherwise, you won't.
> You can find the full list in the Books Online if you look up
> sp_dbcmptlevel.
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://sqlblog.com
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:HoudnQA8uN6nwNXbnZ2dnUVZ_vGinZ2d@.comcast.com. ..
>
>
|||This is an overgeneralization. Compatibility level is mainly concerned with
interpreting TSQL, but to say NO new features will work is not true at all.
Did you look at the page on sp_dbcmptlevel in BOL?
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://sqlblog.com
"James Luetkehoelter" <JamesLuetkehoelter@.discussions.microsoft.com> wrote
in message news:DE983716-D4D0-440B-AEAB-53C61561B12F@.microsoft.com...[vbcol=seagreen]
> Hi Kalen,
> Correct me if I'm wrong, because this is how I explain compatibility level
> when teaching or presenting: the compatibility only tells the query engine
> how to interpret TSQL code. Thus, at 80 no new features will work, nor
> syntax
> changes in 90.
> I'm not missing something, am I?
> "Kalen Delaney" wrote:
|||Thanks, I'll hone my explanation.
"Kalen Delaney" wrote:

> This is an overgeneralization. Compatibility level is mainly concerned with
> interpreting TSQL, but to say NO new features will work is not true at all.
> Did you look at the page on sp_dbcmptlevel in BOL?
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://sqlblog.com
>
> "James Luetkehoelter" <JamesLuetkehoelter@.discussions.microsoft.com> wrote
> in message news:DE983716-D4D0-440B-AEAB-53C61561B12F@.microsoft.com...
>
>

Compatibility level ?

Are there any downsides to changing it from 80 to 90 for a given database ?Hi Rob
It depends...
Does your database have any objects with names that are now reserved
keywords in compatibility level 90?
EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE
Does any of your code use the *= or =* syntax for outer joins?
Does any of your code update a view that was defined WITH NOCHECK that
includes a TOP?
If your database includes any constructs that is allowed in 80 compatibility
but is not allowed in 90, then you will have problems. Otherwise, you won't.
You can find the full list in the Books Online if you look up
sp_dbcmptlevel.
--
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://sqlblog.com
"Rob" <robc1@.yahoo.com> wrote in message
news:HoudnQA8uN6nwNXbnZ2dnUVZ_vGinZ2d@.co
mcast.com...
> Are there any downsides to changing it from 80 to 90 for a given database
> ?
>|||Hi Kalen,
Correct me if I'm wrong, because this is how I explain compatibility level
when teaching or presenting: the compatibility only tells the query engine
how to interpret TSQL code. Thus, at 80 no new features will work, nor synta
x
changes in 90.
I'm not missing something, am I?
"Kalen Delaney" wrote:

> Hi Rob
> It depends...
> Does your database have any objects with names that are now reserved
> keywords in compatibility level 90?
> EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE
> Does any of your code use the *= or =* syntax for outer joins?
> Does any of your code update a view that was defined WITH NOCHECK that
> includes a TOP?
> If your database includes any constructs that is allowed in 80 compatibili
ty
> but is not allowed in 90, then you will have problems. Otherwise, you won'
t.
> You can find the full list in the Books Online if you look up
> sp_dbcmptlevel.
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://sqlblog.com
>
> "Rob" <robc1@.yahoo.com> wrote in message
> news:HoudnQA8uN6nwNXbnZ2dnUVZ_vGinZ2d@.co
mcast.com...
>
>|||This is an overgeneralization. Compatibility level is mainly concerned with
interpreting TSQL, but to say NO new features will work is not true at all.
Did you look at the page on sp_dbcmptlevel in BOL?
--
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://sqlblog.com
"James Luetkehoelter" <JamesLuetkehoelter@.discussions.microsoft.com> wrote
in message news:DE983716-D4D0-440B-AEAB-53C61561B12F@.microsoft.com...[vbcol=seagreen]
> Hi Kalen,
> Correct me if I'm wrong, because this is how I explain compatibility level
> when teaching or presenting: the compatibility only tells the query engine
> how to interpret TSQL code. Thus, at 80 no new features will work, nor
> syntax
> changes in 90.
> I'm not missing something, am I?
> "Kalen Delaney" wrote:
>|||Thanks, I'll hone my explanation.
"Kalen Delaney" wrote:

> This is an overgeneralization. Compatibility level is mainly concerned wit
h
> interpreting TSQL, but to say NO new features will work is not true at all
.
> Did you look at the page on sp_dbcmptlevel in BOL?
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://sqlblog.com
>
> "James Luetkehoelter" <JamesLuetkehoelter@.discussions.microsoft.com> wrote
> in message news:DE983716-D4D0-440B-AEAB-53C61561B12F@.microsoft.com...
>
>