Microsoft
Visual Studio Team Edition for Database Professionals
Community
Technology Preview for Service Release 1
Release Notes
This document
lists the system requirements to install Microsoft Visual Studio Team Edition
for Database Professionals. This document also describes issues that you might
find while you use this release. You can find an online version of this
document, which contains the most recent updates, at http://go.microsoft.com/fwlink/?LinkId=78581.
Visual Studio Team Edition for Database
Professionals has the following system requirements:
·
Visual Studio Professional Edition,
Visual Studio Team Suite, or one of the role-based SKUs of Visual Studio Team
System. The trial version of Visual Studio Team Edition for Database
Professionals requires Visual Studio Team Suite.
o The Visual Basic or C# language
feature must be installed
o MSXML must be installed (It is
installed by default)
o Visual Studio Professional Edition is
included on the DVD for Visual Studio Team Edition for Database Professionals.
·
Microsoft
·
Windows
Vista, Microsoft Windows 2000 with Service Pack 4 (SP4),
You
can order trial versions of Visual Studio Professional Edition or Visual Studio
Team Suite at http://go.microsoft.com/fwlink/?LinkId=78583.
Before you install
Visual Studio Team Edition for Database Professionals, you must uninstall any
earlier version of that product.
You
can install Visual Studio Team Edition for Database Professionals at a command
prompt such that no user intervention is required to complete the installation.
This type of installation referred to as a “silent” installation, and you might
use it, for example, to install the product on several computers simultaneously.
To perform a silent installation, you must create a file that specifies
installation options for the product. You can use this file to install the
product completely or to uninstall it. You cannot use this process to repair or
reinstall the product.
To resolve this issue
To create an information file for unattended installation:
1. Run the Setup application from the installation folder by using the following command line:
Setup\setup.exe /createunattend Path:\infofile.ini
2.
Follow the steps in the setup wizard to complete
the installation.
In effect, you are recording an installation script. When the wizard finishes,
it will produce a file called infofile.ini. You can copy that file so that
other users can perform unattended installation with the same options that you
used in step 2.
Note: The setup application might terminate unexpectedly if you create an unattended installation file to uninstall the product. This termination does not affect the contents of the file, which can be used to uninstall the product.
To use the information file to perform an unattended installation:
· Run the Setup application from the installation folder by using the following command line:
Setup\setup.exe /unattendfile Path:\infofile.ini
If
the language of the version of Team Edition for Database Professionals that you
install does not match the language of your installation of Visual Studio 2005,
you cannot perform unit tests on a database.
To resolve this issue
You must install the version of Team Edition for Database Professionals whose language matches that of your installation of Visual Studio 2005.
If
you are installing Team Edition for Database Professionals onto a localized
platform, the Setup application might fail, indicating that ProjectAggregator2
cannot be found.
To resolve this issue
You can manually install ProjectAggregator2. Locate ProjectAggregator2.msi in the location from where you launched the product installation. Typically, you will find this .msi file on the physical media in the wcu\ProjectAggregator folder. After you have installed ProjectAggregator2, you can re-run the Setup application to install Team Edition for Database Professionals.
If
you must repair or reinstall Team Edition for Database Professionals, you must
have access to the source files for your original installation. For example, if
you originally installed from a DVD, you must have the DVD to repair or
reinstall the product. If you installed from a network share, the same network
share must be available to repair or reinstall the product.
To resolve this issue
If you installed the product from a CD or DVD, put that disc in your computer either before you try to repair or reinstall the product or when you are prompted during the repair or reinstall operation. If you installed the product from a network share, make sure that the network share is available before you try to repair or reinstall the product.
To
install Team Edition for Database Professionals, you must have an existing
installation of Visual Studio 2005, and that installation must have at least
one programming language installed.
To resolve this issue
Before you install Team Edition for Database Professionals, re-run the Setup application for Visual Studio 2005, and specify at least one programming language as part of the installation process.
There are a
limited number of Microsoft
|
|
Source
Database Server |
||||||
|
|
|
||||||
|
Database
Compatibility |
6.5 |
7.0 |
8.0 |
6.5 |
7.0 |
8.0 |
9.0 |
|
|
Not Supported |
Not Supported |
Supported |
Not Supported |
Not Supported |
Supported* |
Not Supported |
|
|
Not Supported |
Not Supported |
Supported |
Not Supported |
Not Supported |
Supported |
Supported |
* - You
can import objects from a
For database
deployment, the following table shows which versions and compatibility modes
are supported for the source database project and target database server.
|
|
Target
Database Server |
||||||
|
|
|
||||||
|
Database
Compatibility |
6.5 |
7.0 |
8.0 |
6.5 |
7.0 |
8.0 |
9.0 |
|
|
Not Supported |
Not Supported |
Supported |
Not Supported |
Not Supported |
Partially Supported |
Partially Supported |
|
|
Not Supported |
Not Supported |
Not Supported |
Not Supported |
Not Supported |
Not Supported |
Partially Supported |
** - You
must have applied SQL Server 2000 Service Pack 4 (SP4) to successfully deploy
your database project with Team Edition for Database Professionals.
If
you have database projects that you created by using a CTP of Team Edition for
Database Professionals older than CTP6, you cannot open them. To implement new
features, some breaking changes were required in the file formats for database
projects, data generation plans, and database unit tests.
To resolve this issue
Create a database project. On the Project menu, click Add Existing Item to add the .sql files that contain your database object definitions. You must manually recreate any data generation plans and database unit tests.
File names for
project items are not necessarily robust to underlying changes. If you change
the name of a file, you might not be able to reload your project.
To
resolve this issue
Avoid renaming the files outside of Visual Studio.
You must
install the MSDN Library that contains the documentation for Visual Studio Team
Edition for Database Professionals for help topics to appear when you press F1.
If
you use
To resolve this issue
There is no workaround for this issue at this time.
To
create and use database projects, you must belong to the securityadmin
and the dbcreator fixed server roles for your
design-time validation database. In addition, if you are not connecting to SQL
Server as a member of the sysadmin role, you must
have
USE
MASTER
GO
GRANT
EXECUTE ON sp_detach_db TO public
GO
To resolve this issue
Have your database administrator add you to the securityadmin and dbcreator fixed server roles. If you run as sysadmin, you already belong to these roles.
If
you have multiple database projects in a single solution, you cannot click one
project, use the Import Database Schema command, and change the target in the Import Database Schema dialog box. Even
if you specify a different project in that dialog box, the schema will be
imported to the project that you initially clicked.
Example:
You have a solution that contains database projects ProjectA
and ProjectB. You click ProjectA
and use the Import Database Schema command. Even if you change the target in
the Import Database Schema dialog
box to ProjectB, the schema will be imported to ProjectA.
To resolve this issue
Click the correct target database project before you use the Import Database Schema command. If you click the wrong target, click Cancel to close the Import Database Schema dialog box, click the correct target, and use the Import Database Schema command again.
You
cannot open a database project in more than one instance of Visual Studio. If
you try to open a database project that is already open in another instance of
Visual Studio, an error appears that says "The design database is locked.
If you are trying to open a database project that is already open in another
instance of Visual Studio, you must first close the other instance."
To resolve this issue
Close the solution that contains the database project in the other instance of Visual Studio.
If you import a schema that has one or
more encrypted objects in it, those objects will not be imported and no error
will appear.
To resolve this issue
You can add the objects to the database project manually. In Schema View, right-click the database project node, point to Add, and click the type of encrypted object that you want to add, such as Procedure.
When you add users to a database project,
if the related logins do not exist, you must add them. You do so by adding the sp_addlogin (SQL Server 2000) or CREATE LOGIN (SQL Server
2005) statements to the Logins.Sql script that the
pre-deployment script includes.
To resolve this issue
In Solution Explorer, expand the Scripts folder, open the Pre-Deployment folder and double-click the Logins.sql file to open it in the Transact-SQL (T-SQL) editor. Add the sp_addlogin or CREATE LOGIN statements, and then save your changes before you build and deploy your database project.
If you stop and restart your local
instance of SQL Server when a database project is open, an error message
appears and indicates that you have lost your connection. Any modifications to
the database project will cause the error message to reappear until you unload
and reload your project.
To resolve this issue
In Solution Explorer, click your database project, open the Project menu, and then click Unload Project. When the project is unloaded, open the Project menu and then click Reload Project. As an alternative, you can close and reopen your solution.
If you add a full-text index to your
database project from Schema View
and your Schema View is sorted by
Type, the file for the index might get created directly under the project node.
To resolve this issue
Sort Schema View by Schema before you add the index. As an alternative, you can open Solution Explorer, open the Schema Objects folder, open the tables Folder, open the Indexes folder, and manually move the script to the Indexes folder after you add the file.
If
you use Team Foundation Build, any non-default values for the Target Database, TargetConnectionString, and DefaultDataPath
properties are ignored.
To resolve this issue
To build successfully from Team Foundation Build, you must modify the ProjectName.dbproj file to add the TargetDatabase, TargetConnectionString, and DefaultDataPath properties from the ProjectName.dbproj.user file for the configuration that you want to build.
If you import database objects by using
the Import Script wizard, no errors appear even if errors are encountered. Any
statements that cannot be successfully interpreted are ignored and files for
them are not generated in the database project.
To resolve this issue
There is no workaround for this issue at this time.
If you import a script that contains DLL
statements that are embedded inside sp_execsql calls,
any objects that are defined within those DLL statements are not added to the
database project. For example, the procedure in the following example will not
be added to the database project:
EXEC dbo.sp_executesql
@statement = N'
-- Proc Comments go here
CREATE PROCEDURE [dbo].[my_proc]
@p1
NVARCHAR(40)
AS
SET NOCOUNT ON
SELECT @p1
'
To resolve this issue
If you have a database that contains the object definitions, you can use the Import Database Schema command into an empty database project. If you must add the missing object definitions to a database project that already contains object definitions, you can use Schema Compare to compare the database to your database project, and then write the additional objects to the database project.
If you add or import triggers, they are
added beneath the Schema Objects folder, rather than beneath the Triggers
folder.
To resolve this issue
You must move the files to the correct location within the database project.
If the Transact-SQL statement interpreter
stops responding while reading an SQL statement, an error appears in the Error List window. Also, a temporary
file that has information about the exception is created in the Windows Temp
folder with a file name of TS Data Guid.tmp.
To resolve this issue
If this error appears, report it through the Microsoft Connect site and attach the temporary file.
If you rename your database project, any
existing .dbproj.user files are not renamed. The
project settings that are stored in the .dbproj.user
file are saved to the new name, but the old file will remain.
To resolve this issue
You must manually delete the old .dbproj.user files after you rename a database project.
The parameters of a stored procedure are
case sensitive if the design-time validation database server is case sensitive,
regardless of the collation setting of the database project.
To resolve this issue
If your stored procedure parameters must be case insensitive, set your design-time validation database server to be case insensitive.
You cannot use the following
statements in the definition file for the specified schema objects:
·
Check
Constraints – ALTER TABLE [ WITH { CHECK | NOCHECK } ] {CHECK | NOCHECK}
CONSTRAINT
·
Foreign
Keys – ALTER TABLE [ WITH {CHECK | NOCHECK} ] {CHECK | NOCHECK} CONSTRAINT
·
DML
Triggers – ALTER TABLE {ENABLE | DISABLE} TRIGGER TriggerName
·
DML
Triggers – DISABLE TRIGGER { [Schema.]TriggerName ON ObjectName
·
Database
Triggers – DISABLE TRIGGER { [Schema.]
·
All
Server Triggers – DISABLE TRIGGER { [Schema.]
·
Tables
– ALTER TABLE { ENABLE | DISABLE } TRIGGER ALL
·
Indexes
– ALTER INDEX DISABLE
·
Full-text
Indexes – ALTER FULLTEXT INDEX ON TableName {ENABLE | DISABLE}
·
Queues
– ALTER QUEUE ObjectName WITH STATUS = { ON | OFF }
To resolve this issue
You must include these kinds of statements in a post-deployment script. For more information about post-deployment scripts, see the product documentation.
In some cases, you might
receive a warning for a valid T-SQL statement that involves JOIN statements
even if SQL Server would accept that statement. For example, you can create the
following view definition:
CREATE VIEW [dbo].[View1]
AS
SELECT column_2 FROM
Table1 LEFT OUTER JOIN (SELECT column_1 FROM Table2 as T_T2) as B on 1 = 1
LEFT OUTER JOIN (SELECT column_1 FROM Table3 as T_T3) as C on 1 = 1
A warning appears for the second “SELECT
column_1”.
To resolve this issue
To resolve the warning, you must fully qualify the reference. For example, you could rework the previous statements in the following way:
CREATE VIEW [dbo].[View1]
AS
SELECT column_2 FROM
Table1 LEFT OUTER JOIN (SELECT column_1 FROM Table2 as T_T2) as B on 1 = 1
LEFT OUTER JOIN (SELECT T_T3.column_1 FROM Table3 as T_T3) as C on 1 = 1
Team Edition for Database
Professionals does not directly support vardecimal
storage as it is implemented in SQL Server 2005 Service Pack 2 (SP2). If you
import a schema from a database that has vardecimal
storage enabled for the database and for one or more tables, the setting is
ignored. No errors appear, and no statements are added to the
ScriptsIgnoredOnImport.sql file. You can build and deploy the database project,
but the build script does not create vardecimal
storage on the database or any tables.
You will also encounter issues
if you import a script that contains the following statements:
-- enable vardecimal
storage format for database
exec sp_db_vardecimal_storage_format 'DatabaseName',
'on'
-- enable vardecimal
storage format on t1 in database
exec sys.sp_tableoption 'TableName',
'vardecimal storage format', 'on'
The statement for the storage
format of the database is imported into the ScriptsIgnoredOnImport.sql file.
The statement for the table storage format is imported into the definition for
the table. You cannot deploy the database project because the statement that
enables vardecimal storage for the database was not
executed, which causes the statement for the table to fail.
To resolve this issue
To resolve the issues that resulted when you imported the
schema from a database, you must add the exec sp_db_vardecimal_storage_format
statements to your pre-deployment script. You can then add the exec sys.sp_tableoption statements to the tables in which you
want to use the vardecimal storage format.
To resolve the issues that resulted when you imported a script, you must add the exec sp_db_vardecimal_storage_format statements to your pre-deployment script.
Only
the first batch statement is processed.
To resolve this issue
Avoid using more than one batch statement in your unit test scripts.
The app.config file in your test project contains connection strings to a database that you are testing. If a connection string specifies an incorrect server or database, database unit tests in that test project fail. Even if you correct the connection string in the app.config file and run tests, the tests still fail.
To resolve this issue
You can resolve this issue by
installing Visual Studio 2005 SP1. If you cannot upgrade at this time, correct
the connection string, rebuild the test project, and then run the database unit
tests again.
You might experience a delay if you open a database unit test in the Database Unit Test Designer and then you open the test’s data generation plan without first closing the designer.
To resolve this issue
Before you open a data generation plan, close the Database Unit Test Designer for any database unit tests that are associated with that data generation plan.
If an error occurs when a custom test condition is loaded, no error appears. However, the test condition does not appear in the list of test conditions in the Database Unit Test Designer.
To resolve this issue
You must fix the issue with the test condition before it will appear in the list.
The Extensions.xml file format has changed slightly from earlier CTPs. You must use the new format for your test condition to appear in the user interface. For more information, see the product documentation.
To resolve this issue
You must update the Extensions.xml file to match the following example:
<?xml version="1.0" encoding="utf-8" ?>
<extensions assembly="<enter assembly name here>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=<enter key here>" version="1" xmlns="urn:Microsoft.VisualStudio.TeamSystem.Data.Extensions" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:Microsoft.VisualStudio.TeamSystem.Data.Extensions Microsoft.VisualStudio.TeamSystem.Data.Extensions.xsd">
<extension type="<enter extension type here>" enabled="true" />
</extensions>
Transact-SQL (T-SQL) code stubs will not be automatically generated for database unit tests for triggers that are based on views. If you right-click on a trigger that is based on a view, the Create Unit Tests menu item is disabled on the context menu.
To resolve this issue
You must manually create a database unit test for the trigger by writing the appropriate T-SQL statements in a new database unit test.
If you create database unit tests that must run on a computer that is set to a different locale than that of the computer on which the unit test was created, you must specify the expected results in the format of the locale where the unit test will be run. This issue primarily effects the Expected Value property for Scalar Value test results. If you want to run unit tests on multiple locales, you must create one test per set of conditions for each locale.
After
you create a data generation plan, if you specify too large a value for the
Rows to Insert field for one or more tables in your database, Visual Studio
might encounter an exception when generating data into your database. The maximum
value that causes the exception depends on the configuration of your database
server.
To resolve this issue
Specify fewer rows to insert. For example, on a 1.7 GHz computer with 1 GB of RAM, we recommend that you insert no more than 1000 rows into each table in the Northwind database.
Before
data is generated for your database, you are asked whether you want to clear
the contents of the selected tables. If you choose to clear the contents of
those tables and the selected tables contain a large number of rows, a SQL
timeout error might appear in the Error
List window. The number of rows required to cause this problem depends on
the configuration of your database server.
To resolve this issue
Use
If
you installed Microsoft
To resolve this issue
For information about a workaround for this problem, see http://go.microsoft.com/fwlink/?LinkId=78584.
When you populate a database, Data Generator
does not take constraints into account. As a result,
To resolve this issue
Change the generator properties to match the table or column
constraints that will affect population. For example, you can change your
generator to the Regular Expression generator and supply a pattern that will
satisfy the constraint, or you can change your generator to the Schema Bound
generator and use data that satisfies the constraint.
If you create a custom generator and that
generator causes an unhandled exception, that unhandled exception might cause Visual
Studio to stop responding or terminate unexpectedly.
To resolve this issue
You must identify and handle exceptions within your custom generator.
You can import a schema from a database
into a database project and then compare schemas using the database as the
source and the database project as the target. However, any permissions
that originated in the source database will appear as missing in the target
(the database project).
To resolve this issue
There is currently no workaround for
this issue. However, to verify the permissions that were imported, examine the
post-deployment script. To open this script, expand your database project in Solution Explorer, expand the Scripts
folder, expand the Post-deployment folder, and then double-click the script.postdeployment.sql file.
Data Compare will always use a ‘.’ as the decimal separator for columns that are decimal or money types, even for locales that use a different decimal separator character (such as a comma). Columns of other data types, such as real and double, will use the correct decimal separator for your locale.
To resolve this issue
There is no workaround for this issue.
If you use a refactoring operation to update
scripts that are stored in Visual SourceSafe, a warning message appears for
each script (.sql) file that the operation updates.
The message reads “There already exists an item with
the same name under source control. If you continue with the
add, this item will automatically assume the identity of the item under
source control. Do you wish to proceed with the add
anyway?”
To resolve this issue
Select the Don’t show this dialog box again (Always allow add of existing items)
check box to keep the message from reappearing.
If
you execute a stored procedure in the T-SQL editor, an error occurs within that
stored procedure, and you double-click the error in the Error List window, you will always go to the first line in the
editor. The line number that appears in the Error List window is the line number within the stored procedure,
not the line number within the editor.
To resolve this issue
Open the source for the stored
procedure to display the line that resulted in the error. If the stored
procedure is defined within a database project, you can double-click the stored
procedure in Solution Explorer or Schema View to open it in the editor.