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
Related
We have a purchased commercial app that accesses a named, locally installed SQL server instance.
Is there any way for us to transparently move the DB to a remote shared SQL Server host, but still have things configured within SQL Server so that the local software can access as it it were a local instance?
Keep in mind, since it's a purchased software package, I don't have the ability to modify the queries it's running, so if tables have to change into fully qualified, or other special T-SQL syntax to make this work, it's not an option.
Effectively, we need to "trick" the app to use a remote database, but access as if it's a local instance (though configuration, some sort of proxy, or perhaps dark magic).
The total extent of the application DB configuration settings is to select the name of the local instance to connect, as shown in this image: .
SQL server is installed on the local machine (Win2012R2x64), and has a couple instances running. I have complete control of both local & remote SQL servers, so can make unrestricted config changes to them. Current DB version is SQL2014, but could upgrade to newer if newer version features are needed to do this.
You can try creating an alias to the remote sqlserver from the local sql server. (Via Sql Server Configuration Manager | Aliases | Add a new Alias name)
Your local instance alias should be the name server name that the connection string is using to connect.
I've used this method in the past to change the sql instance that I was connecting to without changing any connection string info.
More info here
It depends what sort of access the commercial app needs in the locally installed database once the app has set up and created its database.
You will probably invalidate any support agreements in the attempt. Worse still, if a commercial app insists on a local instance then I dread to think what security horrors it will insist upon in your shared instance.
You need to profile the database while the functionality of the application is used to find out what it does and how it does it. Even if you determine that the security permissions could be greatly restricted you may find that the app checks to see if it has a higher permission level.
I've no way to hand of testing this approach but....
Install the app as usual which will be on your local instance
Back up the DB on your local instance and restore the DB to your remote instance. Remember to set up what logins are necessary.
Set up a linked server to on your local instance to your remote instance.
Delete all objects in your local DB instance
Create sysnonyms for all objects pointing at the remote instance.
If it is an application that simply requires direct table access this might work. It is however an ABOMINATION.
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).
I am about to begin a personal project to build my skills in the .net environment. I am familiar with SQL Server Management Studio and how to create a database in it but I discovered how to make a local database in Visual Studio as well. My program is only going to require local database access as it will be used for individual inventory systems rather than connected ones. Am I ok to use the onboard tools in visual studio and create a local databasse or should I be using the SQL Server Management Studio?
When you use the Local Database item template in VS, it creates a SQL Server CE data file (SDF) and adds it to your project. When you use the Service-based Database item templete, it creates a SQL Server (Express) data file (MDF) and adds it to your project.
The advantage of using the VS tools is that the data file becomes part of your project and can therefore be easily deployed with the compiled application. As such, the database is basically part of the application.
If you choose SQL Server CE then you don't need a server installed on the user's local machine. They can install SQL Server CE or you can install it with your app if you want, but you also have the option of simply deploying a DLL with your app and it will work.
If you choose SQL Server Express then the user actually needs a SQL Server instance installed on their machine. To be honest, I'm not 100% sure whether that instance must be SQL Server Express or it can be a full SQL Server instance too. It would usually be SQL Server Express though, which you can install and even download automatically when you install your app, depending on the deployment method you choose.
If you use the VS tools to create an MDF data file then your connection string will contain the Data Source and AttachDbFilename attributes. The Data Source will generally be ".\SQLExpress", i.e. an instance named "SQLExpress" on the local machine. That instance name is not required, although it is the default for SQL Server Express, but it must be on the local machine. The MDF file gets attached at run time and detached again when you're app is done with it. It will also usually be attached to a user instance, which means that other users can't see it, even when it's attached. Note that, in later versions, the LocalDB feature of SQL Server may also be utilised.
If you create your database in Management Studio then it's not actually part of your app. It will be permanently attached to the SQL Server instance so, everyone will be able to see it and open it, assuming permissions allow. Creating the database during deployment will be an extra step in that case. You might create a backup and restore that during deployment or generate SQL scripts that get run. In this case, your connection string will contain the Initial Catalog attribute to specify the name of database to connect to, as well as the Data Source attribute. This option is required if you want multiple clients to be able to connect to the database.
In short, if you are only going to be accessing a database from the local instance of the one application then creating a database in VS is OK and probably a good idea. Whether you choose SQL Server CE or SQL Server Express may well depend on what level of functionality you need.
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.
I am a total newbie in SQL/SQL server stuff, and I am using SSRS to make a new reporting server/service and upload some .rdl files to it
I have a reporting server on a machine, which has a lot of reports and data sources uploaded to it's database.
I created a new reporting server with a fresh database on another machine, and what I want to do is to copy the old database content to the fresh one (the reports and the datasources..etc)
I have no copy of the individual reports to upload them to the new server using localhost/reports
is there's a fast solution to what i am having? please do it in detail because I never worked with SQL before.
Different ways to do this:
Report Server Databases
Use the detach/attach or backup/restore instructions here. Both of these methods require a backup of encryption keys on the existing instance, which are then restored to the new report server instance. Instructions on backup/restore of encryption keys here. Migrating the ReportServer and ReportServerTempdb databases is the easiest way to ensure all content is available on the new server.
Report Object Scripting
Reporting Services Scripter is an older (but still working with SSRS 2008R2, not sure about 2012) tool that can be used to transfer objects (folders, shared data sources, shared data sets, reports, etc) between report servers. Good choice if you want to pick and choose what is migrated.
If you are receiving an error regarding unsupported scale-out deployment, this means you are running Standard edition and need to remove the old report server entry from the database in the new location. It can be done using Reporting Services Configuration Manager, or by using rskeymgmt at command line.
Reporting Services Configuration Manager
Open Reporting Services Configuration Manager and connect to the new report server instance.
Click on Scale-out Deployment to view registered report servers.
Select the old report server instance and click the Remove Server button.
Command line and rskeymgmt
Browse to the Tools\Binn folder of your SQL Server client installation.
Run the following to list registered report servers
rskeymgmt -l -i
Using the installation ID (GUID) of the old report server, remove it
rskeymgmt -r -i
More info on scale-out deployments and rskeymgmt here.
To migrate Reporting Services, use migration manual from MSDN (https://msdn.microsoft.com/en-us/library/ms143724(v=sql.120).aspx). If you encounter "the feature: scale-out deployment is not supported in this edition of reporting services. (rsoperation notsupported)" error, go to ReportServer database and remove the old encryption key from table dbo.Keys.