I'm following a course on edX and I'm using the AdventureWorksLT database for the exercises, everything seems fine.
However, in the Object Explorer I can't see the attributes (columns) of a table.
When I expand the table I see 4 subfolders:
Keys (which generates an error when I try to open it)
Constraints
Triggers
Statistics
No attributes/columns of the table.
Does anyone know how to fix this? I really need this sometimes to see, for instance, the type of attribute (i.e. varchar or int).
The database is hosted on Microsoft Azure and I'm using SQL Server 2014 Management Studio and database.
Related
In SQL Server Management Studio 2017, When I am creating a new diagram & adding a new Table (or adding an existing table) to the diagram,
I am unable to change the Table View type to Custom.
Also, when I am modifying Table View "Custom" to include columns such as Default Value or Description, SSMS fails to update the table view type.
I have tried connecting instances of SQL Server 2008 R2 as well as SQL Server 2016 to the studio.
Is it a bug or is there a setting which I need to change ?
Extra Info : Downloaded it from here https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms
it might be you hit a bug. i've tested it using SSMS 14.0.17213.0 (17.4) and the table view custom is working fine. please check again. You may need to update your SSMS as Microsoft updates SSMS every month to provide bug fixes and add new features.
HTH
In Visual Studio 2013 I am trying to migrate the data from our type tables out to azure. I run the SQL Data Compare tool in Visual Studio, select the type tables, I see that the Timestamp column (which we've named RercordVersion) for the tables is selected. However, when I generate the script, that column is not included.
I checked Tools - Options - SQL Server Tools - Data Compare and the 'Include timestamp columns' option is checked. I unchecked then re-checked and tried again, but it still ignores the Timestamp column.
If I update the target database with the data, then re-run the compare, it wants to insert all the data a second time, since RecordVersion is now different.
Is there something I'm missing?
Is there another way I can replicate/sync/copy my type tables up to Azure?
Update: So I guess my main question is what is the best practice for keeping type tables in sync between on premises db and our azure databases?
I'm assuming this is not possible but asking just in case. I have two database projects in my Visual Studio 2013 solution and Database Y mostly just has shortcuts to tables in Database X. Everything worked great until I added partitioning to the definition of Table A in Database X. Since I deploy Database X to SQL Server 2012 Enterprise and deploy Database Y to SQL Server 2012 Standard, and partitioning is not allowed in Standard, the latter deployment fails.
Is there a way to tell the database project for Database Y to ignore the partitioning stuff? Any other ideas on how to keep the tables in sync without using a shortcut?
UPDATE: Here is the error.
Creating [PartitionByReportFileID]... (75,1): SQL72014: .Net SqlClient
Data Provider: Msg 7736, Level 16, State 1, Line 2 Partition function
can only be created in Enterprise edition of SQL Server. Only
Enterprise edition of SQL Server supports partitioning. (74,0):
SQL72045: Script execution error. The executed script: CREATE
PARTITION FUNCTION PartitionByReportFileID
AS RANGE RIGHT
FOR VALUES (90000000, 120000000, 140000000, 160000000, 180000000, 200000000, 220000000, 240000000, 260000000, 280000000, 300000000,
320000000, 340000000, 360000000, 380000000, 400000000, 420000000,
440000000, 460000000, 480000000, 500000000, 520000000, 540000000,
560000000, 580000000, 600000000);
An error occurred while the batch was being executed.
UPD: Well, it's possible, though you probably won't like the approach.
Indeed, SSDT includes partition-related stuff into the deployment script no matter how hard one tries not to allow it. The other way is to create an empty database and then perform a schema compare between the project (source) and that database (target). In the schema compare settings, make sure 2 checks are set on the General tab:
Ignore object placement on partition schemes
Ignore partition schemes
This works in SSDT 2012, verified. From this point on, you can either run an update directly, or generate script and then use it for deployment, with only minor modifications (such as adding the database (re)creation part from the standard deployment script, if needed).
The only drawback with this approach is that previously partitioned tables appear on default filegroup, which is usually PRIMARY unless you change it. That, and post-deployment script functionality isn't included, afaik (assuming you have one, of course).
I'm new to SQL Server and today I began writing an SQL query. While writing SQL queries in SSMS (SQL Server Management Studio) for insert statements, I noticed that only table names were getting auto completed, but there is no option to auto complete the column name. Is there any way to autocomplete column names in a query?
INSERT INTO table_name (column1,column2,column3,...)
/* Here table name is auto completed. When i type a,a related tables were generated, but for columns there is no autocomplete. */
VALUES (value1,value2,value3,...);
Assuming you are using SQL Server Management Studio (SSMS), which most use people use when working with SQL Server, there is a weaker built in Intellisense that will fill in certain parts of SQL queries for you. If you want something stronger, you can check out third party addins. The most popular are probably SQL Prompt by Red Gate and SQL Complete by dbForge.
I'm working on the old C++ MFC project (> 10 years old). Database application works with migrating from MS Access (2007) to MS SQL Server (2008 R2) and I faced some hurdles on the way. For exporting data I used MS SQL Management Studio ("Import" option in the menu)
As it's known, there are some differences in data types between Access and MS SQL. That turned into some troubles.
Columns "ID" from Access (Autonumber, not NULL, primary keys) become just usual columns in SQL Server (int, not NULL and without any autoincrement). So I got lots of mistakes while inserting new rows into the tables.
Yes/No type in Access (-1/0; NULL is not allowed) becomes bit (1/0/NULL), logic of work shouldn't be broken as in the most of the places it is comparision of being not equal to 0:
query.Select()
.Buff("ID", &code)
.FromS("%Table_Name%", NULL)
.Where().Str("Aktiv <> 0")
.Execute();
Looking for a solution I saw the advice to use SSMA (SQL Server Migration Assistant) for Access. It's much better and more intellectual as it recreated primary/foreign keys, created CHECK's, indexes. But unfortunately lots of the FOREIGN KEYs' action Update/Delete operation become not Cascade but No Action. Warning message after schema import:
FOREIGN KEY constraint "Reference77" on MS Access table %Table1% may cause circular or multiple cascade paths. The cascade option from table %Table2% to table %Table1% was set to No option in SQL Server.
And that's not a surprise application gets some errors while deleting objects, though it was all OK in Access. For testing I selected one delete operation (in application) which got errors. I watched error messages and changed No Action -> Cascade for the involved FOREIGN KEYS via SSMS (SQL Server Management Studio). After that delete operation in the application succeeded.
My questions are:
Am I right I need only to change No Action -> Cascade for the FOREIGN KEYs to get the database application can work completely proper? Or there can appear another issues I don't know?
How can it be realized? I would like it to be a good solution for applying it on clients' SQL Servers.
Thanks for help, I really appreciate it!
Thanks for your answer. The solution for my problem is ... exporting data directly from Access (2010) to SQL Server.
I tried:
"SQL Server Import and Export Data", result - copying of only data from Access database, no any primary oк foreign keys, no transformation of autonumber to a column with IDENTITY and autoincrement.
SQL Server Migration Assistant for Access, result - a lot of foreign keys lost CASCADE property for update/delete operations. But all another things are OK.
Access 2010! Database Tools -> SQL Server -> ... using wizard -> all is OK with schema and data. Application works fine with the SQL Server database imported from Access.
So direct export from Access to SQL Server gave the required result.
Probably, but you will still need to test.
For a reusable solution, I would script the database that SSMA created (checking that all the types and foreign keys are correct). Having this script you can create an empty SQL Server database on any number of servers.
To populate these databases I'd use an Integration Services package. It's very easy to create by using Import wizard: going thru all the steps, but saving the package instead of running it immediately. Then you can open this package and edit it (adding data conversions or any other logic if necessary).