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.
Related
I have SQL Server Management Studio v18.8 looking at a SQL Server 2019 database. When I right-click on a table in a Linked Server Object and choose to "Script table As Select To New Query Editor Window", then many of the columns are duplicated or triplicated.
For example, if my table has these four columns:
UNIT_ID
UNIT_NAME
UNIT_LOCATION
UNIT_LOCATED_DATE
Then the results will look like this:
SELECT [UNIT_ID]
,[UNIT_NAME]
,[UNIT_NAME]
,[UNIT_NAME]
,[UNIT_LOCATION]
,[UNIT_LOCATION]
,[UNIT_LOCATED_DATE]
,[UNIT_LOCATED_DATE]
,[UNIT_LOCATED_DATE]
,[UNIT_LOCATED_DATE]
FROM [MyLinkedObject]..[dbo].[UNIT_LOC]
GO
Is this a known bug? Is there a fix or workaround? I would really like to be able to create and run these scripts quickly, but I'm having to spend a lot of time deleting the repeated copies of the columns.
Im running SQL Server 2005. I was wondering if there is a tool our there that would allow to to say something like:
SELECT top 10 *
FROM ct
And the ct will be converted to CustomerTable
It does not have to be a SQL Server add on, could just be a windows app.
I just find that I keep calling the same tables many times over, and even though I have SQL Complete to autocomplete, it still takes a while to get the full table name out of it.
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 have a bunch of data in MS Access. I want to create INSERT statements from the data with the purpose of running them in SQL Server. The table structure between Access and SQL Server is the same. I don't have the option of doing an export/import because I don't have direct access to the SQL Server. It is a web host's server and they only give you a stupid control panel to run scripts. Unfortunately I can't use SQL Server Management Studio against it, or any other tools.
What is the easiest way to generate SQL Server compatible INSERT statements from MS Access data?
Install a copy of SQL Server (perhaps Express) on a machine (your dev machine, a VM, whathaveyou). Ensure your .mdb can be read by this machine.
Use SQL Server to create a Linked Server to your Access database.
DTS/SSIS tables from Access to your local SQL Server.
Export scripts + data from your local SQL Server. Right click your database, select Tasks-> Generate scripts.
choose to script data.
This will ensure that your create statements are followed by the data.
Consider using a mix of Access and Excel.
View your Access table in datasheet view.
Select all rows
Paste into Excel
Insert a new column before Column A.
Build your INSERT statement in this cell.
Insert a comma between each column (insert new column) and single quotes as needed
Insert an end parenthesis
Drag the INSERT statement, commas, and end parentheses downward, copying their values for each row in your table.
ensure you set SET IDENTITY_INSERT MyTable ON before executing that script.
It turns out I found a way that was easier than either of the suggested answers. I went to SQL Server Management Studio and right-clicked on the database, chose Import, and went through the wizard to import from an MS Access datasource. It was fairly painless and straightforward. Then I generated scripts as p. campbell suggested.
I have a SQL Server 2005 instance, into which I am trying to import data from a SQL Server 2008 instance using an SQL Query. I am using the 2008 management studio, and the import/export data wizard.
If I run the select query separately in the management studio, it correctly returns the ~88k rows that are required. The query returns the data with the exact column names and types required by the destination table.
When I run the import wizard, the sql query parses correctly, and the 'Preview' button correctly shows the data. There are no errors or warnings in the conversion section. The task is set to fail if there are any failures in conversion.
When I run the task, no errors are displayed. However, it shows '0 rows transferred' and no data is imported.
Any ideas why?
edit: tried importing to a table created on import in a fresh new db, and still the same result. I'm wondering if the direction of movement from 2008 to 2005 is important (i.e. 2005 can't handle a 2008 feed correctly).
If you have "USE [database]" as part of your query, then this single line is all that gets executed during the import/export.
The solution is to remove the "USE" statement as part of your query.
I've never had much luck with the SQL server management studio's import features under 2005/8.
Lately, I do one of two things.
Either I just use it to import the data into a brand new table on the target server (not even a table of the exact same structure) then run an insert statement to transfer from that newly created table into the destination.
Or I use a tool like Visual Studio for Database Professional (or Redgate) to transfer the data.
I've used the import successfully. Chris has a good suggestion (this is the process I typically follow) though on using a middle table or file. That gives you the ability to do some simple transforms using queries rather than SQL's transform tool. It also gives you a buffer in case things go wrong or you need to isolate issues.
I had a similar problem using the import utility for 2008. We had Oracle native SQL that ran fine in TOAD but imported with 0 rows using the SQL Server import utility. The culprit ended up being related to Oracle's date format. The SQL referred to dates such as '03-JUN-2013'. Once I changed them to use the TO_DATE function such as TO_DATE('06/03/2013','MM/DD/YYYY') we had a successfully execution and import.