Adventureworks version 631 error

I installed Sql Server 2005 Express Edition on an XP system thismorning and tried to attach Adventureworks, but got an error messagestating:

The database 'Adventureworks' cannot be opend because itis version 631. This server supports version 612 andearlier. A downgrade path is not supported.

Since both SqlServer 2005 Express Edition, Management Studio, and the Adventureworksdatabase have all be downloaded within the past three days, I amastonished that there is a compatibility issue. I have runAdventureworks on other systems without problems. Any suggestionson how to proceed?

Hi Moonshadow,

Where did you download that "Adventureworks" ?

Please make sure you are downloading the correct AdventureWorks database for SQL Server 2005. The CodePlex website contains two versions of the database, one for SQL Server 2008 and one for SQL Server 2005. If you are viewing the AdventureWorks database download release for SQL Server 2008 you must click "SQL Server 2005 SP2a" in the Releases box on the right hand side. You can also use the following link to download the SQL Server 2005 version directly at:http://www.codeplex.com/MSFTDBProdSamples/Release/ProjectReleases.aspx?ReleaseId=4004.

Detailed information, see:http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1966875&SiteID=1

thanks

This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these sites and has not tested any software or information found on these sites; therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet.

|||

Hi B.C. When I originally searched for the DB I was redirected tothe Codeplex site where the current default download version is for SqlServer 2008, hence version incompatibility. I tracked down andinstalled the 2005 version at Codeplex and all is well.

Advantages of SQL Server

hi ! my boss is thinking of redoing our accounting system which is currently running on FOXPRO - we are planning on a VB/SQL SERVER platform.but he isn't convinced that the benefits of SQL server outweigh those offered by FOXPRO especially since everyone in the office is very comfortable with Foxpro.Can anyone give me some solid advantages of SQL SErver or any other RDBMS over Foxpro ?http://dbforums.com/arch/125/2003/2/689282|||FoxPro?

Accounting?

Security?

I got it...how 'bout an abacus, quill and parchment...

Ok...enough with the sillyness...guess they keep advancing it...why? I have no idea..

http://gotdotnet.com/team/vfp/

What version of foxpro?|||A couple of observations...

VFP and MS-SQL are not mutually exclusive. You can have the benefits of both if you choose. SQL Server can provide the "back end" at the server, and VFP can provide the "front end" at the client.

SQL Server allows much better security, eliminates damaged files due to workstation disconnects, better performance, practically infinite ability to scale.

-PatP|||I still have a Programmer's Manual for FoxPro 2.0, right before it was bought up by M$. It presented a serious competition to Borland's dBase IV, and gave me an opportunity to really dive into SQL...Anybody wants to buy 19 Installation disks (1.44MB) for FoxPro 2.6 with a Connectivity Kit?|||Still got your Access 1.2 disks?

;)

First consultant gig was on 2.0

:D

Now where did all the side business go?

:(|||I've still got a set of 5 1/4 Paradox discs (pre-Windows). 8:)|||Hey, Paradox 4.0/4.5 was my next step (actually a step backwards in regards to SQL) I believe I still have them too, not sure about the version...Anyone?|||...And I also have the first decent VB for DOS, 2.0. Fits on 2 1.44MB floppies, very compact and suitable for travel. Very low minimum system requirements, produces beautiful forms and popup dialog boxes ;)|||Sorry, my old Kaypro doesn't have 3 1/2 inch drives. Just the old 360KB floppies. No HD either.|||I still have a pair of 8" floppies with Vulcan on them.

-PatP|||I knew I should have kept my first program! But carting all those punch cards around got to be a real pain (literally!) :)|||I tossed my paper tape after the program went into production!|||okay..

i used to get up each morning 3 hrs before i went to sleep and clean the road with my tongue, for 3 cents a week. considering the shoebox at the bottom of the lake that we lived in had a rent of 32 cents a week, we had to do a lot of odd jobs.

my first for pay consulting job was at mr slate's quarry.
i used to maintain(feed) the first database ever created called "joe" after it's creator "joe". it used a series of stones tied to sticks attached to a pelican. and through a series of levers we could calculate pi to 1 place in 7.3 hours.
being a very exclusive database, there was only one copy and since it was a bit on the gamey side, it couldnt be kept indoors.

i have a copy in a storage container in my back yard, it's not totally oledb compatible but with a bit of work it could be dblibrary.|||Wow! You still have a copy of the "Joe" database? What a coincidence! At the back of one of my file cabinets I still have the original RFP I submitted for the project.

Did you know it was actually a conversion from an older legacy system?|||nope your thinking of "joe's" weaker sister "mary" it wasnt even a database per se.
the storage mechanism was elephant turds and while being easy to find, were not very portable and therfore would harden after a few days making the db unusable.
we considered mary to be effetively a slowly created statue not a database.

i have a "mary" coffee table if you need some living room furniture.|||Ruprect, the elephant dung can be softened by the application of moisture. This should have been part of your regularly scheduled maintenance plan.

Really, you should have paid more attention to Books On Rocks. It was full of usefull examples. I guess back then you must have been a rookie DBA (Dung Ball Administrator).|||what is it with you
even on older databases your books online is still out of date

[Books On Rocks] Stone Package 3

in the last release of "Mary" database there is no need to apply moisture to the mammoth dung as it is considered a "wasting asset"

you will have to rebuild the dung clusters with fresh dung every one to two weeks for proper retireval.

everyone knows that you will change the "flies" sort order if you moisten the dung

what an ultramaroon..

update your books on rocks|||I stand corrected. I guess my only excuse is that my thinking has been fuzzy and muddled ever since I stumbled upon a strange black rectangular monolith in the woods...

I concede that your knowledge of Dung Ball Administration is much deeper than mine. Knee-deep, even.

Advantage of using Catalog views

Hi,

Can anyone tell the advantage of using the new catalog views over the traditional system tables which were given as compatiblity views in sql server 2005

The compatibility views will not be upgraded to support newer metadata information (post-2000), also because some of the limits such as user numbers have increased the old views will error or return NULLs if the value ranges for the old system tables are exceeded (see - http://msdn2.microsoft.com/en-us/library/ms187376.aspx).

Basically you are locked into a view of the database that does not allow for all the features in SQL Server 2005 if you use the compatibility views.

|||

for all new feature SQL Server 2005 , you have use Catalog views or DMVs. Compatibility views are only for backward compatibility , which will be removed in the next version. All the new development work should not use Compatibility views.

Madhu

ADO.NET OleDb SET ROWCOUNT or DBPROP_MAXROWS

I am writing a data access tool that needs to be non provider specific. I have used System.Data.OleDb to access a variety of data source types (MSSQLServer, MSAccess, MSExcel, CSV, Oracle, XML). This works beautifully. Thankyou Microsoft for giving us ADO.NET2.0.

However, I now need to restrict the number of rows returned from a SELECT statement. Is there any way I can I achieve this in a non provider specific fashion?

So far searches have yielded DBPROP_MAXROWS however I can find no way of setting the DBProperties using ADO.NET2.0. Is this possible?

Documentation for DBPROP_MAXROWS states that it uses "SET ROWCOUNT n" as part of the command text. I tried this and it works but not for the JET4 provider (this is a problem since I use JET4 to access .mdb, .xls and .csv files)!

Any tips here would be greatly appreciated. Even if somebody were to tell me that it's just not possible, at least that would put me out of my misery :)

Thanks.

Because of the way JET accesses data, bringing all of the data to the client before processing the criteria, I don't think that there is a way to make that work.|||

Thanks for the reply Arnie,

since posting I have done some more research and discovered that using TOP works for Jet. This is good for me as it also works for SQL Server. The approach I have taken is as follows:

int maxRows = 100;

string someQry = "SELECT * FROM table1";

string topQry = "SELECT TOP " + maxRows.ToString() + " * FROM (" + someQry + ") as topSubQry";

However it doesn't work for XML files. To get data from XML files I use a connection string of "Provider=MSDAOSP.1;Data Source=MSXML2.DSOControl.2.6;" and then the full path to the XML file as the command text. I am guessing there will just be no way to limit the rows returned when using this provider.

ADO initialization fails on W2003

OVERVIEW:
ADO initialization fails on W2003 Server, Standard Edition.
This is a new system.
This is the first time this app has been compiled or run on this system.
The app runs fine on all other servers I've tried it on.
What should I check?
Is anyone else able to run ADO routines against OLE 5.2?
Thanks,
Brad.
DETAILS:
OLE32.dll v.5.2.3790.250
OLEAUT32.dll v.5.2.3790.0
Tracing into the code, I get into
_WStrAsg("", "'ISAUTOINCREMENT'");
which calls SysReAllocStringLen. This fails with an access violation.
SysReAllocStringLen is a call into OLEAUT32.dll.
All the OLE32 dll look to be updated. They are newer than anything
on any of my XP systems.
I have a new test project that uses ADODB and it *doesn't* fail.
Yes, it does go through the same code just as nice as you could want.
The same app is deployed an running on dozens of other systems.
None are as new as this one.
So my guess is that it has to be something about the way the new
system is set up.
My next step is to start tearing down a copy of my project. But I'm
not terribly hopeful.
Thanks,
Brad.Long shot but is the bad project compiled on the same library as the working
one. Also, have you updated to the latest mdac + fixes.
-oj
"Brad White" <bwhite at inebraska . com> wrote in message
news:OQLP18vDFHA.2540@.TK2MSFTNGP09.phx.gbl...
> OVERVIEW:
> ADO initialization fails on W2003 Server, Standard Edition.
> This is a new system.
> This is the first time this app has been compiled or run on this system.
> The app runs fine on all other servers I've tried it on.
> What should I check?
> Is anyone else able to run ADO routines against OLE 5.2?
> Thanks,
> Brad.
> DETAILS:
> OLE32.dll v.5.2.3790.250
> OLEAUT32.dll v.5.2.3790.0
> Tracing into the code, I get into
> _WStrAsg("", "'ISAUTOINCREMENT'");
> which calls SysReAllocStringLen. This fails with an access violation.
> SysReAllocStringLen is a call into OLEAUT32.dll.
> All the OLE32 dll look to be updated. They are newer than anything
> on any of my XP systems.
> I have a new test project that uses ADODB and it *doesn't* fail.
> Yes, it does go through the same code just as nice as you could want.
> The same app is deployed an running on dozens of other systems.
> None are as new as this one.
> So my guess is that it has to be something about the way the new
> system is set up.
> My next step is to start tearing down a copy of my project. But I'm
> not terribly hopeful.
> --
> Thanks,
> Brad.
>
>
>|||Thanks for the reply.
The first thing I checked was MDAC, and yes it is 2.8.
I thought last night that perhaps it is a 2003 thing,
but no, we have had installations for months on 2003 Server
with no problems.
Same libraries. Tried the debug versions of the libraries in both exe's
with same results.
"oj" <nospam_ojngo@.home.com> wrote in message
news:uMArKKwDFHA.2032@.tk2msftngp13.phx.gbl...
> Long shot but is the bad project compiled on the same library as the
working
> one. Also, have you updated to the latest mdac + fixes.
> --
> -oj
>
> "Brad White" <bwhite at inebraska . com> wrote in message
> news:OQLP18vDFHA.2540@.TK2MSFTNGP09.phx.gbl...
>|||Brad,
Perhaps, reinstall the package?
-oj
"Brad White" <bwhite at inebraska . com> wrote in message
news:%23LzC%23$3DFHA.3924@.TK2MSFTNGP09.phx.gbl...
> Thanks for the reply.
> The first thing I checked was MDAC, and yes it is 2.8.
> I thought last night that perhaps it is a 2003 thing,
> but no, we have had installations for months on 2003 Server
> with no problems.
> Same libraries. Tried the debug versions of the libraries in both exe's
> with same results.
> --
> "oj" <nospam_ojngo@.home.com> wrote in message
> news:uMArKKwDFHA.2032@.tk2msftngp13.phx.gbl...
> working
>|||"oj" <nospam_ojngo@.home.com> wrote in message
news:u34aoVAEFHA.3732@.TK2MSFTNGP14.phx.gbl...
> Brad,
> Perhaps, reinstall the package?
>
Thanks for the reply.
The way it was acting reminded me of memory corruption,
but I couldn't see how that could be since no custom code
had run yet.
Turns out it was an unrelated dll improperly installed.
Reinstalling that to solve another problem, solved this problem.
It wasn't an ADO thing or WideStr thing at all.
--
Brad White

ADO Connection to MSSQL Server 2005... Need help

Hi,

at first a few things about my system:
I use Visual Studio 2005 Pro on WinXP SP2 and I have recently installed MSSQL Server 2005 Express on my system.

I want to establish a connection to the MSSQL Server from C++ (not .NET) using ADO.

For this I use the following connection String:

Open(L"Provider=SQLNCLI;Server=FREECASTLE;Integrated

Security=SSPI;DataTypeCompatibility=80;MARS

Connection=True;",L"",L"",ADODB::adConnectUnspecified);

This works. But this is not exactly that what I wanted, because here

just my Windows Authentication is used. I want to be able to pass

username and password for users that are allowed to access the SQL

Server. Here my first confusion begins: I have the option to pass the username and password into the connection string (User Id and Password) or I guess that I can pass them also as parameter 2 and parameter 3. But with trying both of these options I get always a connection error that my specified Username is not be trusted ( I don't know how the message looks in the English version, because I have the german version), but I suppose you know what I mean.

Of course I have to create such accounts in the SQL Server before trying to login with them. I guess that I made something wrong when doing this. I started the Server Manager Studio and there I navigated into the Object Explorer. In the folder Security I created a new account for testing (using SQL Server Authentication). But I cannot use that account for logging in.

I have to admit that I am very new to the SQL Server thing, so I hope someone can help me or can give me hints on what to do better. I am very thankful for every reply...That specific error message means, that you only enabled your server for WIndows authentication, if you want to use also SQL Server authentication you will have to enabled it first (using mixed Authentication). See the Screencast on my site for more information about Changing the authentication mode in SQL Server.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||Hi Jens,
with your Screencast I solved my problem. Thank you very much for your help.

ADO Connection issue

Hello All,

I have made a small application on my system in delphi v7 that uses the ado connetion components and works fine on the remote sql server db. But my client gets a "cannot find server" on his system with the sql server/db local.

My connection string this...

Provider=SQLOLEDB;Password=password;Persist Security Info=True;User ID=USER;Initial Catalog=MyDB;Data Source=SERVER01;

his connect is...

Provider=SQLOLEDB;Password=password;Persist Security Info=True;User ID=USER;Initial Catalog=MyDB;Data Source=HISSERVER01\APP;

I have changed the Data Source to (local) and local, as seen in another post but this had not effect. We have check his MDAC version verse mine and they are the same, save he has sp3; I have sp1.

...any ideas?

The SQL Server of your client is a named instance, you need to make sure that the Data Source string matches the instance that you want to connect to in the format of <servername>\<instancename>. Also, local is not valid, (local)\<instancename> or localhost\<instancename> are ok. If you want to connect to a remote named instance, you also need to enable SQL Browser service if the remote SQL instance is SQL Server 2005. -HTH|||

Thank for answering :)

But I may have not been clear. we are not sharing a database. He has his own copy running on his lan, I have mine running on my lan.

Both systems are running on XP systems.

On his; he is running the client app locally to his sql server. His connection of <server>/<instance> is correct

On mine; the client is remotely accessing the sql server. I did not setup an instance, so just using <server> should be valid.

I wonder if the instance requires additional parameters to be passed, any ideas?

TY,

CJ

|||Which version of SQL Server are you using ? If you are using SQL Server 2005 you will have to enable remote connections, switch on the SQL Browser in order to connect to another port than the default one 1433, or name the portnumber after the servername with the syntax Servername,portnumber.

HTH, jens Suessmeyer.

http://www.sqlserver2005.de

ADO Connection issue

Hello All,

I have made a small application on my system in delphi v7 that uses the ado connetion components and works fine on the remote sql server db. But my client gets a "cannot find server" on his system with the sql server/db local.

My connection string this...

Provider=SQLOLEDB;Password=password;Persist Security Info=True;User ID=USER;Initial Catalog=MyDB;Data Source=SERVER01;

his connect is...

Provider=SQLOLEDB;Password=password;Persist Security Info=True;User ID=USER;Initial Catalog=MyDB;Data Source=HISSERVER01\APP;

I have changed the Data Source to (local) and local, as seen in another post but this had not effect. We have check his MDAC version verse mine and they are the same, save he has sp3; I have sp1.

...any ideas?

The SQL Server of your client is a named instance, you need to make sure that the Data Source string matches the instance that you want to connect to in the format of <servername>\<instancename>. Also, local is not valid, (local)\<instancename> or localhost\<instancename> are ok. If you want to connect to a remote named instance, you also need to enable SQL Browser service if the remote SQL instance is SQL Server 2005. -HTH|||

Thank for answering :)

But I may have not been clear. we are not sharing a database. He has his own copy running on his lan, I have mine running on my lan.

Both systems are running on XP systems.

On his; he is running the client app locally to his sql server. His connection of <server>/<instance> is correct

On mine; the client is remotely accessing the sql server. I did not setup an instance, so just using <server> should be valid.

I wonder if the instance requires additional parameters to be passed, any ideas?

TY,

CJ

|||Which version of SQL Server are you using ? If you are using SQL Server 2005 you will have to enable remote connections, switch on the SQL Browser in order to connect to another port than the default one 1433, or name the portnumber after the servername with the syntax Servername,portnumber.

HTH, jens Suessmeyer.

http://www.sqlserver2005.de