Change DB server at runtime - vb.net

I have a large vb.net project running on subsonic 2.2.
I am looking for a way to change the connection string for subsonic at run-time, based on a separate configuration file. (basically connect with the sever information in my own configuration file.)
How can this be accomplished?

Related

spring boot switching from in-memory database to persistent database

I have developed my web-application using spring-boot and spring-data-jpa and and in-memory database, and I have a couple questions:
how can i now switch to a persistent, let's say, MySQL database? What do I have to change in my configuration?
Can spring-boot set a database up for me with a specific port and where does it get stored in my file system?
Does IntelliJ provide a datasource browser for the created database?
I am sure this must be covered somewhere in the endless jungle of spring-boot documentation.
You can change the application properties for the datasource according to the link Gabor Bakos already provided.
That depends on the type of the database you want to use. HSQLDB and H2 allow you to specify a file path for the database file, however the database instance itself is still running within your application process. With full RMDBS like MySQL you have to install and configure the MySQL server yourself and provide the connection data to your Spring Boot application.
Yes, IntelliJ has a datasource browser for all major databases (maybe you have to download the database driver).

Programmatically updating connections or dynamic connection managers

I will take your guidance for both a 2008 and 2012 environment, as I will need to be upgrading this project.
I have an SSIS 2008 project where I need to initially run the whole data flow into a staging environment, and after all is good, I need to switch every target to go into a production environment:
Each of these controls has another lawyer of data flow complexity. if you drill down to this one for example:
you will see that this control has more to it, and there are components inside of it depending on the different connection managers:
**how do i easily switch between using connections pertaining to one environment vs connections that pertain to another environment in ssis 2008 or 2012? **
I would consolidate the Connection Managers down to a single set - i.e. remove the "Prod" versions. Then I would add SSIS Package Configuration to set the connection details, e.g. via an XML Configuration file for each Connection.
I would have a copy of the Configuration files for each environment e.g. in sub-folders. If they all need to be executed from a single machine I would swap the Configuration files as required.
Depending on your deployment scenario you might prefer the other Configuration options e.g. Environment variables, SQL - I think Config files are the easiest and most obvious to set up.

Pentaho Report Designer - Dynamic Data Sources

I have a local instance of the Pentaho Report Designer running on my box and it has a local development database configured as its data sources. (2 datasource configs, both pointing to the same local data server; source and target databases.)
Obviously, when I publish this report to the production BI server the reports fail because my local datasources are no longer reachable.
Clearly configuring the report to rely on the production databases would resolve any identity crisises (crisi?) but I live in the sticks so network is slow and I don't want to impact the production DB for development purposes.
In Kettle, I have updated the kettle.properties file to provide localized datasource variables (Great for unit testing my transformations!) and was wondering if there is a similar method for localizing variables in PRD?
In PRD, you use JNDI connections to have the same sort of abstraction. You can find the JNDI configuration in $HOME/.pentaho/simple-jndi. Create a datasource there and a datasource with the same name in the BI-Server's admin-console. Then define your connection as "JNDI" connection type and mention that name you given your datasources.
Then, depending on whether you run local or on the server, the engine will lookup the connection info from the runtime context.
But one warning: Given the fact that SQL is not a real standard, make sure that your local and remote environment use the same database type. Otherwise, if you - for instance - use MySQL on the client and Oracle on the server, your SQL created for MySQL will not be accepted by the oracle driver and vice versa.
On Windows you find the jndi config file here:
C:\Users\(username)\.pentaho\simple-jndi

Develop for SQL Server Standard using SQL Server Express?

I'm working on a web service project, and I'm coding at home, where I have SQL Express 2008 installed, but the app needs to interface with an SQL Server Standard. I've never done the transition before, and I haven't been able to find any resources on the subject - plenty of stuff about upgrading, but nothing about how to deploy.
For instance, Visual C# Express, I don't seem to be able to connect to a database without a database file - is that how Standard works as well? Do I just deploy the file with the application?
You can use the Express version also as a stand-alone installation. See here for example. In fact, there is also a free edition of Management Studio. You can manage your database the same way as any other edition. If you install SQL server express in this way, you can move to another version of SQL server without a hitch!
Unless you are doing something very very unusual or something hacky, the deployment will be very easy. Anything that I know of that you can do in the Express version works exactly the same in the full version.
All different ways of connecting to the database are available in both the Express version and full version. You don't need any database file to make a connection, unless the framework that you use requires it. You always connect to the database server through the network, never through the file system.
When you deploy the application you just change the connection string so that it points to the live server. If the login is set up the same way on that server, it works without any other changes.
I think you'll have to manually create the connection string as the IDE won't automatically generate ones connecting to SQL Server Standard Edition. But you can easily record two in the app - one for testing that points to the EXPRESS instance, and one for the live that points to the real one. As long as you're connecting to the same objects and interacting with them in the same way, it should be fine.
You can manually amend your connection string AFTER the IDE has generated its own to something like :
Data Source=ServerName;Initial Catalog=AppDatabase;Integrated Security=True;Persist Security Info=True;Connect Timeout=30
replacing ServerName and AppDatabase as required, and with possible authentication changes. You'll have to watch for the IDE recreating the original connection string, though, as I can't see a way to modify the connection string used in the Database Explorer and if you use the IDE to drag datasources into your app it'll keep using the original connection string.
SQL Server Developer Editions are pretty cheap, though - easily less than £50.

How can I load different endpoints for WCF in SQL CLR?

We're deploying some new WCF calls in our SQL 2005 DB using the CLR. In testing, I hardcoded in the code the endpoint to connect to, and deployed it to our test server. When we go to deploy this to production, we will be deploying it to many different SQL DBs, and using different endpoints to connect to (same service running on different servers). How can something like this be done? Is there a config file that can be referenced for the deployment of the dll into SQL?
The solutions above would work, but we found that the best practice approach would be to create a new table storing all of the different endpoints into the DB. Then, we updated the CLR to make a call to this table to get the endpoint(s) that were needed. So each server would have the proper metadata loaded for it, and it would all be retrieved from the DB. No hardcoding this way, and there's no need to worry about external text files on the SQL server. It's all contained in the DB.
Accessing Application Configuration Settings from SQL CLR
another technique..