I've switched to Eclipse Juno, which claims not to support SQL Explorer. So I want to start using the stand-alone SQL Explorer, but I don't want to have to re-enter all my connections.
Where does the Eclipse SQL Explorer plugin save its settings, and where does the SQL Explorer stand-alone app store its settings, so I can copy them over?
So, after some research, I have an answer. The Exclipse SQL Explorer settings are stored in
<your-workspace>/.metadata/.plugins/net.sourceforge.sqlexplorer/
The same is true for SQL Explorer. However, SQL Explorer doesn't give you any way to specify the "workspace" to use. On the Mac, you need to "Show Package Contents" on the SQL Explorer app, then drill down to Contents/MacOS/ to find the workspace folder.
Related
I've installed VS 2015 sp3 + ADLA Tools 2.2.5000.0
When i click Cloud Explorer -> Select a U-SQL Table -> Preview By Running a Job, it runs a U-SQL job that pulls some data to a csv file and next i can preview the file.
But some people show the screen bellow at forums. Where i can find it in GUI? Maybe ADLA Tools installed incorrectly :). Or maybe these people have an access to a beta versions of ADLA Tools?
The screenshot is for a Local table. You should be able to do the same for your Local tables. Right-click a Local table and there will be a "Preview" option.
Please suggest How to Generate the scripts from Microsoft Parallel Data Warehouse...
I have already tried using SSMS 2016 by using my PDW credentials...
But i failed to Generate the scripts...
Regards,
Abhishek
The first thing I would try is to go to SSMS 2016 and go to the Tools menu and choose Check for Updates. Install the latest update out in the last month or so supports Azure SQL DW which is a similar MPP surface area. It may support PDW but I'm not sure.
If that doesn't work, go the tried and true route. Search the Microsoft download center for Analytics Platform System Appliance Update and then choose the version that matches your PDW. Download the .chm help file. Then you have to right click on the .chm file and choose Properties then unblock it in order to open it.
Then search for "Install SQL Server database tooling for Visual Studio" and it documents how to install SQL Server Data Tools for Visual Studio and connect SQL Server Object Explorer. Then you can expand and view a list of tables/sprocs/etc and script them out by right clicking on a table or sproc in SQL Server Object Explorer.
I have a SQL Server Scripts 2012 Project with multiple SQL queries and stored procedures.
We use Team Foundation Server 2012 to manage our source code for our Visual Studio Solutions.
How can I check in a SQL Server Scripts 2012 Project into TFS? If it is not possible how can I manage source control on this and allow multiple developers access to it?
You have a few options, here are two that I have used.
1: Download the TFS 2012 MSSCCI Provider:
This plugin allows you to access TFS from Microsoft SQL Server Management Studio. So you can easily add and check in\out those ssmssln and ssmsproj files from TFS.
64bit Download - 32bit Download
Once installed, in SSMS go to Tools-> Options -> Source Control to select the plugin.
If you don't see it then you probably need to install the other bit version.
After you have selected the plugin in the options window of SSMS, you will have a new menu option under "File" that will allow you to Add\Open\Change items in TFS from Sql Management Studio.
To add your Scripts solution using the MSSCCI plugin:
Open the project in SSMS, go to File -> Source Control -> Add Solution to Source Control
2. Add through VS using the "Add files to Source Control"
See here: To add a file that is not in a solution to version control
I'm not quite sure why it would be a challenge to add the sql server scripts to TFS just as any other file in your visual studio solution. I've done this in a lot of projects with great success.
What is a challenge with databases though is to find a good strategy to handle branches and database versioning. I recommend that you have a look at Entity Framework Code First Migrations which handles this very nicely. Another approach is to use Chuck Norris Round house which is a more script based solution:
RoundHouse
https://code.google.com/p/roundhouse/
Code First Migrations.
http://msdn.microsoft.com/en-us/data/jj591621.aspx
If you start from scratch I would recommend the Code First Migrations approach, but if you allready have a lot of .sql files the second can work very well.
The latest versions of MSSCCI still don't seem to work with SSMS 2012 - you'll need an older 32 bit version, here: http://visualstudiogallery.msdn.microsoft.com/en-us/bce06506-be38-47a1-9f29-d3937d3d88d6
Once this is installed you'll be able to see the "Team Foundation Server MSSCCI Provider" in the SSMS Source Control Plug-In selection.
I have designed an Application tracking details and I have deployed it. The records are updating the way I need. I want the same application to be used in other three different systems which do not have MS Visual Studio. How can I do it ? Is it enough that I create a similar table in the path I have designed in the other systems and run the Application ?
The probably easiest way to deploy your project would be:
Copy & Paste the whole output from your bin folder to the other machine and make sure the .net framework you used for your application is installed on this machine.
You can also create a Setup and Deployment Project
Open the Solution of your application
File -> Add -> New Project...
Other Project Types -> Setup and Deployment -> Visual Studio Installer -> Setup Project
In the File System Tab right-click on "Application Folder" -> Add -> Project Output and Select "Primary output" from your application project.
(More details about adding files to your setup project: How to: Add Items to a Deployment Project)
If you want to use a copy of the access database on each machine
As you're using an access database. You can mark the include you're access database to your project and set Build Action (in the Property Page) to Content.
Now in the same manner as before rightclick on "Application Folder" and add project output. Only this time select "Content Files" instead of "Primary Output"
Build the setup project and distribute the setup.exe or the .msi file.
If you want to access the same database from each machine
I would advise to store the application on a server which runs independent of your machine so that others can access the database also when your machine is not running.
Change your connectionstring, so that users from other machines are able to connect have a look at this site if you need help with connectionstrings.
As you won't be able to connect to the database with the absolute filepath from other machines, create a fileshare where everyone who should be able to connect has permissions to read/write.
Build the setup project and distribute the setup.exe or the .msi file.
Hope this helps so far.
Why should there be VB language on the target computer? Once compiled(published) you are out of the language environment and the program is in the machine language. In order to publish you have to go to "Build" and "Publish" after opening the program in the language environment. Publish it to a flash drive instead of the C drive. You can do that by selecting the "Browse" option. Once done you can take the flash drive around and install it on most computers that have the .Net files installed. In my experience most windows opss have them.
Just create an Installer after you have written and debugged your program. Install it plus your database on the server computer. If you intend to share the database and its a file-server database such as Ms Access, you will have to make sure that the folder is a shared folder.
Go to all the other computers on the network and repeat your installation. Make a Mapped drive on each computer and configure your database string to point to the mapped drive. If your database a server one like SQL Server, you will need to configure your database access string to point to the Server like so:
\Syl-PC\SQLEXpress.MydatabaseName
I assume that you are familiar with the complete syntax for connecting to databases from Visual Basic using a database provider such as Ole db or the SQL Server Provider.
Argh! I created an SSIS package via an Import Wizard and I can't find the SSIS packages on the server using Management Studio. Execute an SSIS package doesn't appear as an option when I go into job scheduler, either.
When you start SSMS, it allows you to choose a Server Type and Server Name. In the server type dropdown, choose "Integration Services" and connect to the server.
Then you'll be able to see what packages are in the db.
The wizard likely created the package as a file. Do a search on your system for files with an extension of .dtsx. This is the actual "SSIS Package" file.
As for loading it in Management Studio, you don't actually view it through there. If you have SQL Server 2005 loaded on your machine, look in the program group. You should find an application with the same icon as Visual Studio called "SQL Server Business Intelligence Development Studio". It's basically a stripped down version of VS 2005 which allows you to create SSIS packages.
Create a blank solution and add your .dtsx file to that to edit/view it.
If you have SQL Server installed there is also a menu option for finding local SSIS packages.
In the Start menu > All Programs > 'Microsoft Sql Server' there should be a menu option for 'Integration Services' > 'Execute Package Utility' (this is available if SSIS was included in your SQLserver installation).
When you open the Execute Package Utility, type your local sql server name in the 'Server Name' textbox and click on the Package button, you will see your saved package in the popup window. From here you can run your previously saved package
Open SQL server Management Studio.
Go to Connect to Server and select the Server Type as Integration Services and give the Server Name then click connect.
Go to Object Explorer on the left corner.
You can see the Stored Package folder in Object Explorer.
Expand the Stored Package folder, here you can see the SSIS interfaces.
If you deployed the package to the "Integration Services Catalog" on SSMS
you can retrieve the package using Visual studio.
Came across SSIS package that schedule to run as sql job, you can identify where the SSIS package located by looking at the sql job properties;
SQL job -> properties -> Steps (from select a page on left side) -> select job (from job list) -> edit -> job step properties shows up
this got all the configuration for SSIS package, including its original path, in my case its under “MSDB”
Now connect to sql integration services;
- open sql management studio
- select server type to “integration services”
- enter server name
- you will see your SSIS package under “stored packages”
to edit the package right click and export to “file system” you’ll get file with extension .dtx it can be open in visual studio, I used the version visual studio 2012
you could find it under intergration services option in object explorer.
you could find the packages under integration services catalog where all packages are deployed.