Good evening/morning/after/noon.
I have an ASP.net 3.5 website and I am using vb.net in VWD 2008 Express, I am also using MS SQL Server 2008 Express, I used ajax tabs and a textBox charavters counter control develped by https://web.archive.org/web/20211020202742/https://www.4guysfromrolla.com/
The database is attached with MS SQL Server Management Studio Express and the files are stored in the SQL default "Data" folder.
The whole project's code and forms are stored in a folder in my E drive.
I need to hand the whole project to another coworker who have to finish it, please describe in steps how can i make my website portable (like i can put it all in a folder that he can carry around in his flash disk).
PS: I have had a problem trying to move the project from one server to the other, the pproject seems to look for the dlls of the AJAX control and the textBox counter where i originally unzipped the folders in which they cam in, which i think was on my desktop, although when i added those controls to the Tools tab, i created a new tab, then i choose the dll from the where i unzipped the controls source code, aint that enough?
Thanks in advance
When you create the structure, make a folder for referenced files in the source tree. You can then reference from there. If you do that the entire tree is portable. The only changes, from environ, to environ, are configuration elements. And, if on the local system, you use SQL Express and put in the App_Data folder, it cana connect to your coworkers system, as long as he also has SQL Express.
Related
I edit the template "Create Stored Procedure (New Menu).sql" with the template-explorer. And saved it. Restart ssms.
But if I create a new stored procedure by right-click in the object explorer and then "new -> stored procedure..." the changes are not visible. It seems ssms uses an standard-template I can't find...
If I call the template via template-explorer I can see my changes.
The template I changed is saved at C:\Users\breuerp\AppData\Roaming\Microsoft\SQL Server Management Studio\18.0\Templates\Sql\Stored Procedure.
Is there any other place? How to change the template ssms uses when clicking menu?
Google finds only instructions how to change the template - I did it like the hits described ir - or where they are saved - the place I find my template...
I'm using ssms Version 18.6 and with this infos:
SQL Server Management Studio 15.0.18338.0SQL Server
Management Objects (SMO) 16.100.41011.9 Microsoft Analysis
Services Client Tools 15.0.19205.0 Microsoft Data Access
Components (MDAC) 10.0.17763.1 Microsoft MSXML 3.0 4.0
6.0 Microsoft .NET Framework 4.0.30319.42000 Operating System 10.0.17763
The paths mention in Customise default 'New Stored Procedure' SSMS 2008 Template do not exist on my pc.
Sincerly
Peter
Looks like the templates are intended to start your own collection of starting points for frequently used scripts. Nowhere does the documentation state that it will import or include your custom templates in SSMS.
The documentation states the following (without higlights).
The first time the template explorer is opened, a copy of the templates are placed in the user's folder in C:\Users, under AppData\Roaming\Microsoft\SQL Server Management Studio\130\Templates.
Perhaps if the original location could be retrieve and the original scripts adjusted, then you might see changes in SSMS.
Create custom templates for tasks you perform frequently. Organize your custom scripts into the existing folders or create a new folder structure.
If creating a new folder structure is suggested as possible practice, but there is no option to configure the new folder path in SSMS, then there is no way for the application to find your custom templates.
I have very a rudimentary understanding of Microsoft Access and VBA Code.
On my work desktop, I have Microsoft Office Professional Plus 2013 Access
I've been tasked to create a MS Access application with an Access DB.
I started developing an MS Access application with Forms , and the corresponding DB
I'm using VBA code event handlers(or Event Procedures) for the UI control buttons.
I wanted to create a common configuration settings area for said application( like ASP.NET web application have web.config files or app.config files )
I failed to find anything similar for MS Access application development.
Could someone please provide me with an explanation as to how to implement an MS access implementation model/software design pattern for common configuration settings area that is modular, reusable, clear and concise?
As noted, I great way to do this is to simply create a table in the front end. It is assumed that you will split your database into two parts. The code/forms etc. is the so called front end,and then you have the back end part (the database - it can be a accDB file, or it can be say SQL server).
So the typical update and deploy of your software will be:
Re-link your tables from test database to the actual live production database.
Compile your accDB into a accDE.
Deploy this new updated "next" version of your software to all the desktops.
So, since any change or addition to settings will be in the new front end then any application wide settings you have will thus roll out with your update.
It often depends on the user base. In the case that we had multiple customer sites running our software, then using a local table would not suffice, since things like path names, connection strings to the database etc. are customer specific. So, in this case we moved the settings table out to a text file (setup.ini). So we now use a setup.ini file that is external to the program and assumed to be deployed in the same folder as the front end. On startup we use the windows API to read ".ini" files.
So, both ideas (external setup.ini) or a local table in the front end are rather good choices from a development cycle point of view.
So once you down the road in developing your application, and the table/data structure changes are down to a dull roar, then it is time to split your application. (use the built in split wizard for this). I will say that even for my .net applications, I still often use a external setup.ini file for settings, since once again with multiple customer sites, it not practical to have customer specific settings in the application as opposed to a external settings file.
I am working on a team that have a number of developers working with SQL Server, developing stored procedures, functions etc.
I would like a consistent layout between the SQL, same header with a copyright etc. SO I need a standard template for the SQL. I know in Visual Studio it is possible to share templates.
How can I generate such a template for SQL Server Management Studio that I can share between developers?
This is how I do it:
the physical location of my template is in(Win7 SQL Server Management Studio 2012):
C:\Users\ys\AppData\Roaming\Microsoft\SQL Server Management Studio\11.0\Templates\Sql
I created my own folder in it (00_Mine)
Created a git repository
Asked other devs to pull from it.
In SQL Server Management Studio, press Ctrl-Alt-T or go to Menu, View, Template Explorer
It will list all the templates. However, from SSMS, there is no easy way to add templates to it by drag and drop, you can create new ones and put them into a folder, such as _WORK_.
The templates live physically in (for 2008 R2): C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\SqlWorkbenchProjectItems\Sql, so you can simply drop files and folders in there or push out to team members using group policy. The templates are sorted alphabetically, hence the suggestion for _WORK_ above. Note: A restart of SSMS is required to pick up Template Folder changes.
Here's an article: Using SQL Server Templates
Question to users of template functionality: do you think it will be helpful if you had a possibility to have placeholders for data like: Current database, Current User, Date/Time (something else ?), so, when you open the template these placeholders would be replaced by appropriate values. I develop an add-in and had this idea a time ago, but I do not know if someone really needs it.
Right now I have a project called reports with several reports. In solution explorer it looks like this:
Shared Data Sources
-- DEV
Reports
-- Report1
-- Report2
-- Report3
I want to make it look like this and have the same structure carry over to the report manager website when I click deploy.
Shared Data Sources
-- DEV
Folder A
-- Report1
Folder B
-- Report2
-- Report3
Anyone know how to do this?
I'm using SSRS 2005 - I think this part of it works in the same way as 2008.
As far as I can tell, you can't have folders within projects, but you can have multiple projects within a solution.
To create a new folder, right-click on the solution in the Solution Explorer and select Add>New Project...
Type in your new Project Name (eg. MyProject), and select Report Server Project from the list of Visual Studio installed templates. Click on OK, and your new Project should appear at the end of the list of projects in the Solution Explorer.
(There are other ways of setting up a new Reports project, but this seems to be the quickest.)
If you now right-click on your new Report Project and select Properties, you can see the TargetReportFolder, which will default to your new Project Name (eg. MyProject). When you deploy reports from SSRS, they are deployed to this location. (You can change the location, if you wish - I find it easier to keep track of what's going where by using the Project name.)
You will need to copy any data sources to be used in each project, into the data sources folder of all projects that use that data source. By default, OverwriteDataSources is set to false, so when you deploy a new report, it will use the data source already deployed to the Report Manager environment.
So to get the Report Manager structure that you want to see:
Create Projects called Folder A and Folder B
Move/copy Report1 into the Reports folder in Project Folder A
Move/copy Report2 and Report3 into the Reports folder in Project Folder B
Move/copy data source DEV into the Shared Data Sources folders in Projects Folder A and Folder B
Deploy your reports
Don't forget to check your changes into source control.
The way do it is similar to other posters, I have one solution with multiple projects (each project is named and put into the same folder name that I want it deployed under).
Then I rigged up a script in RS which:
- Creates a single data source used by all reports, in my case
- Loops through all directories in the solution folder
-- Creates the same folder name on the RS server
-- Deploys all files in this directory to that folder on the RS server
-- Uses rs.SetItemDataSources on each report to redirect it to my main data source
And that's basically it.
Caveats are you sometimes get files uploaded you didn't want to (like deleted reports with the .RDLs still hanging around). But you can script all around that, or just blow it away in RS and re-upload again.
Doing this, I have one script but can deploy a structure under numerous different parent folders, each with different data sources, and have all the reports in a folder drawing data from a different database. This lets me run 1x RS instance but have development, testing, training, etc areas.
We manage this with Linked Reports in SSRS. We deploy reports to a Report Distribution folder, hidden from users, then create Linked Reports in the Reporting Services web UI (an option in the Manage section for each report). You can create the Linked Report in any folder, so you can build the folder structure you want and put the linked reports in the appropriate place.
You can deploy everything to the single distrib folder from VS, and the linked reports are updated. This solves the sub-report and DataSource issues since all reports 'run from' the distrib folder. There's obviously a lot of setup up front, and creating a new environment is a hassle - It happens so infrequently that we haven't tried to automate it.
I have a BI project going in SSRS2008 with roughly 80 reports - and this is my experience with deploying reports into folders. This is my first foray into developing in Reporting Services, so any gurus please smack me if I'm out to lunch.
Initially, I used folders in source control to separate smaller reports by department to help keep me organized. That worked fine while I was initially developing my reports, however the first time I deployed the project to the report server the structure was completely flattened - so I gave up on using a folder structure to organize.
As far as I'm aware the only way you can create a folder structure in SSRS is to use the Report Manager UI and create folders on the Report Server. I'm assuming from there you would modify the path in the report properties in Visual Studio. Either that or you have to define the path when you first set up the report. I haven't tested this so YMMV.
So in conclusion: It is not possible to create the folders in BIDS and deploy your reports into folders utilizing the IDE. I hope this is addressed in 2008R2 because it's kind of a pain having all those reports thrown together in the Solution Explorer.
You can have the files in separate folders on the disk/source control however they list flat and sorted alphabetically in Visual Studio.
I cannot see a user interface to manage the above thing but if you edit the project file (single project file of a VS solution) you can specify the FullPath XML tag of each report file.
I created a report server type project and had no option to add another project. Instead I edited the SLN file and added my other projects. The first part of the SLN file then looked like this in the end to access my 2 projects in sub folders to the SLN file
Microsoft Visual Studio Solution File, Format Version 10.00
Visual Studio 2008
Project("{F14B399A-7131-4C87-9E4B-1186C45EF12D}") = "RestOfWorld", "RestOfWorld\RestOfWorld.rptproj", "{D24D5EEA-88A4-4375-802B-7CA877202787}"
EndProject
Project("{F14B399A-7131-4C87-9E4B-1186C45EF12D}") = "NorthAmerica", "NorthAmerica\NorthAmerica.rptproj", "{C64A3BDC-F526-4037-AD48-31799BECC3AD}"
EndProject
Global
#skiwii is correct, with VS 2013 Community edition and SQL Data Tools -- Business Intelligence, you do not see the Solution node at the top of the tree in VS Solution Explorer, and you do have to hack the .SLN file to expose it.
Start with the desired master .sln and one .rptproj file in your source tree. call that 'parent'.
Create a brand new, empty Report Services .rptproj file in a new subfolder (under the folder containing the .sln). e.g, project is 'child1'. VS will also give you a child1.sln file in that folder.
Close all VS windows.
With your favorite text editor (teco!)
open child1.sln.
Copy the 2 lines at the top; Project... and EndProject
Open parent1.sln
Paste those lines under the existing Project / EndProject.
Now open parent1.sln in VS. You will magically see the Solution node at the top of Solution Explorer window.
If you have been very lucky, you will also see a second project called child1. But if not, no problem. You can just right click on the solution and Add a new project of type Report Services.
I have a solution that contains multiple reporting projects (one per target deployment folder - I think this is the only way to achieve this effect, at least until I abandon Visual Studio for report deployment).
I want to specify my data source information "once and only once" for all these reports.
So far, I have created a separate reporting project that contains my shared data source. If I deploy things to a reporting server in the right order and offer sufficient prayers to appropriate gods, the reports seem to link up to the shared data source there and run (at least via the Report Manager in IE).
When I am developing a report, though, I can no longer "Preview" to try it out locally - I now must deploy it to a report server to try running it. This is a hassle.
Is my only recourse to add a whole bunch of copies of a data source (pointing at my development database), one in each project, set those not to deploy off my machine, and (probably) exclude them from source control?
A technique (dirty trick?) I am playing with now is to copy my data source (.rds) into each project, close Visual Studio, then in the underlying files/folders:
Delete the copied .rds from my report projects (leaving only the one copy in my Data Sources project)
In each report project's project file (Foo.rptproj), change the text of the Project.DataSources.ProjectItem.FullPath element from My Shared Data Source.rds to ..\Data Sources\My Shared Data Source.rds
This way all reporting projects reference the same underlying file on the filesystem, so they share a single data source definition, but each project also kind of has a "local" shared data source, so Visual Studio is kept happy.
Regarding source control: there is still only one copy of the .rds checked in, so we're not polluting the code base with lots of icky duplicates; the changes to the .rptproj files can be checked in, so we're not forcing developers into unnatural source-control gymnastics (selective partial commits etc.) to maintain a sane master copy.
Each reporting project will try to deploy this data source, though I've forbidden the overwriting of existing data sources on the server, so it's not too big a deal . . . and I suppose if I intended to overwrite the server's data source definition, it wouldn't really matter whether I overwrote it once or ten times with the same .rds.
Disclaimer: this is still an experiment. I don't have experience using this technique in practice yet, so I can't go so far as to actually recommend it.
Woody,
What we have tended to do is:
On the server have a folder called "DataSources", which is hidden from the users. In there will be all of the data sources.
For each reporting project in VS there will be a folder, also called "DataSources", but this time it will only contain the data source for this report.
As long as the folder structure is the same (i.e. report and data source have the same corresponding folder level on server and in VS) this seems to work for us.