I'm working with WinForms a project that has a couple of oddball requirements. This is an existing business system that is installed in numerous locations under a fairly wide variety of environments. Part of this variety is a mixture of SQL Server versions, and--of particular importance--SQL Server Reporting Services versions. Everyone is on at least 2005, but about 50% of our users are on some flavor of 2008.
Unfortunately for me, I need to be able to run a client-side report that's written in 2008-version RDL. I can't modify the report in any substantive way at this point, so rewriting it in 2005-version RDL isn't an option. The catch is that this report (as it's written in 2008) requires the 2008 ReportViewer control. However, the 2008 ReportViewer control cannot connect to 2005 SSRS.
The solution that I've come up with is more than a little hacky, but it will alleviate 90% of the problems introduced. I've left the references pointing to the 2005 version of ReportViewer, and I'm modifying the application configuration on startup to add assembly binding redirection tags moving from version 9.0.0.0 to 10.0.0.0 for ReportViewer.Common and ReportViewer.WinForms if the user's target report server is running 2008.
As twitch-inducing as this solution is, it's working for me. The users running SSRS 2005 can still access their existing reports, just not the new one. The users running SSRS 2008 can access everything. My only problem is that I haven't been able to find a way to refresh the configuration data. I'm updating this info before any of the assemblies are loaded, but calling ConfigurationManager.RefreshSection("runtime") doesn't appear to have any effect. Once the app restarts, the proper assemblies are loaded, but I'd really like to be able to have this change take effect immediately.
Any thoughts on how I can force the runtime to reload the binding redirection information from the App.config file at runtime?
Once the AppDomain is created, the configuration data that affects binding is fixed. Which happens on the default CLR when the primary AD is created, before your code starts running. If you are really desperate then you could create a secondary AppDomain and give it a custom AppDomainSetup with another ConfigurationFile. And loads and run your regular startup code in that AD. Not exactly sure what kind of side effects this might have.
Related
I have several SSRS reports that need to be transferred to another server. Currently, all reports and SSRS reside on the same exact server as SSMS and all databases. I was wondering if there is a simple way to essentially take everything I have on SSRS (All Reports) and transfer them along with their data sources to the new server that I have. I know downloading all reports and uploading them to the new server is an option but I was wondering if their is an easier/more logical way to go about this process. After completion, SSRS and the SQL Server will be on different servers but still able to work together.
I have had really great experiences with an old (2007) program called "SSRS Scripter" (from Jasper Smith). It seems like it has been absorbed into a newer product called SqlServerFineBuild (which I have never used). The original stuff is a little hard to find, but very nice to work-with, imo.
Microsoft also has another product called Reporting Services Migration Tool (free) https://www.microsoft.com/en-us/download/details.aspx?id=29560 It is a command-line util and isn't the easiest or most-helpful. It has a UI-mode, but it isn't very user-friendly.
Both of these will only extract report files and settings from an existing site. You still need to use VStudio (+ reporting add-in) (and then some RS project work/design/config) to re-deploy.
We originally dismissed using database projects in conjunction with TFS as our solution for our deployment and soucecontrol needs. However, in the interest of thoroughness, I'm exploring and prototyping it.
I've set up my database project (with add to source control checked). I've checked in the changes. Now, where do you develop from?
I've tried ...
connecting to the remote development server to make changes
syncing schema to (localdb)\Projects and making changes there
directly in the Source Control Explorer
With option 1 and 2 I don't see an automated way to add code to source control. Am I suppose to be working in the Source Control Explorer? (this seems a little silly)... Is there a way to commit the entire solution to source control? My apologies in advance, I'm a database developer and this concept of a "solution" is very foreign to me.
Also there were a lot of chatter about Visual Studios doing a lot of ugly things in the back ground that turned a lot of development shops off of database projects. Can someone share your experiences with me? Some of the pitfalls and gotchas.
And yes, we have looked at Redgate SourceControl (very nice tool).
Generally people do one of two things:
Develop in Visual Studio, via the Solution Explorer. Just open the project like you would any other project, add tables, indexes, etc. You even get the same GUI for editing DB objects as you get in SSMS. All changes will automatically be added to TFS Pending changes (just like any other code change), and can be checked in when you're ready.
Deploy the latest DB (using Publish in VS) to any SQL Server, make your changes in SSMS, then do a Schema Compare in Visual Studio to bring your changes back into your DB project so they can be checked into TFS.
I've been using DB projects for many years and I LOVE them! Every developer I've introduced them to, refuses to develop without them from that point on.
I'm going to explain you briefly how we use DB projects with TFS.
We basically have one DB already done and if we require any changes or new tables we create them or alter them directly in SQL Server (each developer has its own dev SQL Server).
Then in VS from the SQL Server Object Explorer we drag the tables we want into the DB project so when we check in the changes, every user in TFS would be able to get them and then publish that project that will generate and execute a script into the DB.
This is the way we use to develop when we need to add specific tables or records to the DB so we don't have to send emails with scripts or have them stored in an specific location (even with source control). This way we can get latest version of the project and publish it to ensure we have the latest DB version although it requires the user (who made the changes) to add them to the DB project.
Other way could be to do all the changes (and can be done without any problem) directly in the DB project and then publish it. That one would be a more right way to do it so you do all the changes directly in a source controlled project, but as you know, is always more comfortable to work directly through the SQLMS.
Hope this helps somehow.
We use the SSDT tools and have implemented the SQL Server Database Project Type to develop our databases:
http://www.techrepublic.com/blog/data-center/auto-deploy-and-version-your-sql-server-database-with-ssdt/
The definition of database objects and peripheral SQL Code (e.g. functions, sprocs, triggers etc) sit within the Visual Studio project and all changes are managed through VS. The interface is very similar to SSMS and, at this point doesn't cause any issues.
The benefits of this approach for us are as follows:
An existing SQL database can be imported into the SQL Server Project and managed through Visual Studio.
SQL object definitions & code can managed through the same version control system as the rest of the application code.
SQL Code can be checked for errors within Visual Studio in much the same way as you'd check your C# / VB for compilation / reference errors.
You can compare database schema's (within Visual Studio) between environments and easily identify key changes that you need to be aware of.
The SQL project can be compiled into a DACPAC file for automating deployment to different servers using a CI / Build Server (using the sqlpackage.exe utility without any custom scripts or code).
In essence developers can have a local version of the database to work on but would manage any changes through VS, then publish the changes to their local database. Once the changes are complete, the changes are committed to your version control system and then built centrally & automatically through a CI / Build server to ensure that all changes integrate and play nicely in much the same way that your other code is.
Hope that helps :)
Presently I have a Windows Forms application that obtains data from a SQL Server database on a separate server in our LAN. Basically we want to re-use as much as possible our source code that interacts with the SQL Server database and change the forms portion to a thin client silverlight solution. The problem is that our Windows Forms application is a fat client application; however, our company recently added employees working several thousand miles away, so they have a long delay in working with our application as it retrieves data from the database server which is a long ways away from the employee's client forms application.
The ideal solution for me would allow the developer to display data based on various database tables or views dynamically at runtime say based on what treeview item a user clicks and not having to hard code the database schema at design time. This is the way our windows forms application presently works.
One aspect of silverlight I am wrestling with right now is that if you want to access data from a SQL Server database on the web server side you have to use web services or WCF RIA, which of course involves creating a design time EDMX file or generating LINQ to SQL classes. The problem is that our database schema changes quite frequently, so that means I would have to keep manually re-updating the web services along with the EDMX and/or LINQ to SQL. What I would really like to do would be to just connect to the SQL Server database using ADO.NET to populate the various silverlight datagrids without having to deal with web services. Please note that I am pretty new to Silverlight, so perhaps I am missing something obvious.
Here is one of the many links I have checked as I've been working on this solution; however, this just migrates a Windows Forms application that already has a web service to a silverlight application that has a similar web service, so it doesn't seem to apply to my situation:
http://www.silverlight.net/learn/advanced-techniques/moving-from-windows-forms/migrating-a-windows-forms-application-to-silverlight
Here is another website that I have been looking at closely; however, the database that I am working with is so huge and has such a large schema that whenever I attempt to open or work with the Data->Show Data Sources or Data->Add Data Source window in Visual Studio it takes about an hour of the CPU running at full throttle before it displays the values in visual studio. Of course this makes Visual Studio almost unusable if this hour long wait happens every time I try to make a change in the silverlight XAML designer:
http://msdn.microsoft.com/en-us/gg315272
Also, the website example above is not an acceptable solution because we want the web server and the database server to be two separate machines, so we would not be able to put the database into the App_Data folder in the silverlight solution.
If anyone has any suggestions or guidance in terms of migrating this application, they would be most appreciated. TIA.
Roger
Basically I found out that since I'm used to writing desktop applications that communicate directly with a database (such as SQL Server), I was surprised to find that there is no object in Silverlight to enable you to do (SqlConnection, OdbcConnection, etc.). This is because Silverlight is a client platform, designed to be run from within a browser anywhere in the world, and so it does not make sense for it to be able to access databases directly because databases are generally hidden behind a firewall. The purpose of a service is to provide an interface for exposing data publicly from the server, acting as a conduit between the data in the database and external applications. (source: "Pro Business Applications with Silverlight 5" by Chris Anderson)
Please note that I also had made a mistake when I created a DomainService and assigned to it all the tables, queries, and stored procedures in the entire database, when in fact one needs to create a separate domain service for each individual table or query. This explains why I had the problem before where I had to wait about an hour for the Data Sources window to populate.
I have a large number of reports that only seem to load when working with MS Visual Web Developer Express. When I put application into production, all my reports just spin and then show nothing.
We need a lot more information to give you a good answer. There are many reasons why this could happen. One possibility - the data source is different on the server than on your local PC. Keep in mind - when you deploy a report to a SQL Server Reporting Services server, and you overwrite an existing report, your newly deployed report will keep the old data source of the report you're overwriting; It will not automatically use the datasource you were using on your development machine if it was previously using something else.
Check in profiler if the Database dou think is accessed is accessed by reportserver.
If not check the datasource in http://yourreportserver/reports/
Have you tried running IE8 in compatability mode?
#mike, as you said, while you already check and recheck the data source but still some user can use the report, and some other dont.
Lets have some scenario. User A work on PC A001 can use the report, while user B, work on PC B001 cannot use the report.
Please recheck whether user A still able to use the report in PC B001? if that the case, the problem is in the user right. but if not the problem is in IE/machine configuration.
hope that helps.
I've been searching for some time for a good solution to implement the idea of managing schema on an SQL Server Compact 3.5 database.
I know of several ways of managing schema on SQL Server Express, SQL Server Standard, SQL Server Enterprise, but the Compact Edition doesn't support the necessary tools required to use the same methodology.
Any suggestions/tips?
I should expand this to say that it is for 100+ clients with wrapperware software. As the system changes, I need to publish update scripts alongside the new binaries to the client. I was looking for a decent method by which to publish this without having to just hand the client a script file and say "Run this in SSMSE". Most clients are not capable of doing such a beast.
A buddy of mine disclosed a partial script on how to handle the SQL Server piece of my task, but never worked on Compact Edition. It looks like I'll be on my own for this.
What I think that I've decided to do, and it's going to need a "geek week" to accomplish, is to write some sort of a tool much like how WiX and NAnt works, so that I can just write an overzealous XML document to handle the work.
If I think that it is worthwhile, I'll publish it on CodePlex and/or The Code Project because I've used both sites a bit to gain better understanding of concepts for jobs I've done in the past, and I think it is probably worthwhile to give back a little.
Edit on 5/3/2010:
If someone is willing to "name" the project, I'll upload the dirty/nasty version that I've written for MS SQL to CodePlex so that maybe we can start hacking out a version of SQL Compact. Although, I think with the next revision of the initial application that I was planning, I'm going to be abandoning SQL Compact and just use XML Files for storage, as the software is being converted from an Installable package to being a Silverlight application. Silverlight just gives a better access strategy.
I am currently looking into Migrator.Net.
This allows you to write changes to your database, called migrations, directly in C#.
These migrations can contain everything from simple table additions/drops, column modifications, to complicated data update code.
When your application boots, it can verify what version the database is currently in and apply any migrations that are required to bring it up to date. All this is handled automatically. The code to run this update is as simple as:
Assembly asm = Assembly.Load("LocalModels.migration");
Migrator m = new Migrator("SqlServerCe", "Data Source=LocalModels.sdf", asm, false);
m.MigrateToLastVersion();
I am having a couple minor issues with the Compact support (it assumes the default schema is dbo). But I don't think it will be too difficult to fix them.
some random thoughts (not sure I can fully answer though)
the Microsoft Sync Framework is one option. I haven't had a chance to fully appreciate what it can do once you've deployed it after the initial first time (which seems to work fine). There's a MSDN site for it here
You can execute scripts on a mobile device, but not through something like SQL Management Studio, so in theory you could manage/maintain T-SQL scripts but the down side is that the T-SQL would be convoluted (to CE's supported statements) and I don't know a way to "automate" execution - but the Sync Framework might hold some answers..
If one of your key criteria is going to be working efficiently over a small pipe, the only real choice you have is to store a DB Schema Version (maybe somehow tied to the scripts checked into your CMS) and when an update is needed, the change scripts are sent over the wire and applied in order. You would probably want to keep a log in your DB as well of these scripts being applied so you can gracefully handle disconnects, reboots and other potentially nasty problems.
Is SQL Server Management Studio any use for you?
http://technet.microsoft.com/en-us/library/ms172933.aspx