I have multiple SQL Server databases with the same schema. I would like to use one WCF data service (Rest service) to access the different databases.
How can I accomplish this so the client can pass in the correct database name or connection string?
You could define some query string parameters, something like:
http://YourServer/YourService/SomeUrl?database=MyDatabase1
and then in your server-side code, use that database=MyDatabase1 to dynamically build the connection string, that you then use to open a connection to the database. Shouldn't be too hard, I think!
Related
I have three identical database servers (DDL wise) that my application connects to.
I want let application users decide which database they want to connect to.
This is a ASP.NET Core 2.1 API project, which implements both service and repository patterns (database queries are called using Dapper, but this can be changed).
I could simply put server name as a parameter in my Domain project, but I don't want this to know anything about database servers we have, neither I want my Repository to know that there could are multiple servers.
So it's just application side that can decide which database server to connect to at run-time.
I was able to find samples and suggestions for EF Core, but not much for anything else, particularly Dapper.
So my question is. How would I let users change database server at run time while keeping domain and repository unaware that multiple servers are there?
So in this case I would suggest having your connection strings either stored in environment variables or appsettings.json files. Lets say the user wants to access "server1" , this would come in from your api and you could then get out the relevant connection string in your repository layer like so
var connectionString = Environment.GetEnvironmentVariable(serverToUse);
Where serverToUse is "server1" passed in from the api. I prefer storing my connection strings in environment variables as its stored directly on the host machine, instead of the application. You could also do this via appsettings
"Server1" : "Your connection string here" in your appsettings.json
You could also do this in your service layer and have the service layer pass the connection string to the repository . Pick your flavor. In this case the repositories are not concerned with what connection you are using as long as its present in either environment variable or appsettings.
I have went through documentation and its a bit hard for me to grasp how one should go about writing adapter for anything. I want to ease the access of RESTful web services with SQL like interface for business folks.
Coarse requirements look something like:
Register data source, in this case endpoint
Add mapping for endpoint to table
Execute simple select queries
Allow joins to be performed on the basis of some join key but in client application memory
Represent the output in the tabular format
Try using Calcite's file adapter, which was just added in release 1.12.
The simplest use case is reading and parsing a CSV file from the file system, and presenting it as a table that can be used in a SQL statement. But in addition to files, the file adapter read documents via HTTP, and it can parse the contents of HTML tables. So you should be able to use it to read data from a REST service.
My client wants to run arbitrary SQL SELECT queries on the backend database of our web app, for ad-hoc reporting purposes. The requests will be read-only. Suppose the choice of analysis tool is flexible, but might include Access or psql. Rather than exposing the database on the public Internet, I want to transmit SQL queries over HTTP.
Can I implement a web service that would allow database analysis tools to communicate with the database using a user's web app credentials? E.g. instead of the database connection string starting with postgres://, it would start with https://. Ideally I'm looking for a [de facto] standard way of doing this.
Related but different/unanswered:
Communicate Sql Server over http
Standards for queries over SOAP
I'm not aware of a standard for this. MK has a point, this sounds like a huge opportunity for a SLQ Injection attack. Services expose the results of database queries all the time. They're typically requesting a handful of parameters and exposing a well defined response. Giving a public user of the service carte-blanche to run any query they want, means that you have to ensure that they don't sneak in a drop database or delete from table query some how. It can be tricky to defend. All of that said, I've seen this pattern used for a private service to pool the connections that the database server is aware. Database connections tend to be pretty expensive.
I have doubts between two options:
Build the query in client side and send it to server.
Sending from client the needed knowledge in order to build the query in server side.
In which side I will prefer to build the query?
Advantages / Disadvantages?
Thanks.
I tend to prefer building queries on the server side and either storing them as Stored Procedures on the sql server or building the query string in a backend language like PHP.
Building the query in something like javascript and sending to the server, creates the possibility of deviants doing inline altering of your javascript and submitting the query string through something like firebug. If you build the query string in a backend (server-side) language, the only thing the user would have access to alter would be input variables (if applicable). Because of this, you should always check and cleanse all input variables for sql injection.
Removing as much access to raw code from the end user as possible seems to always be the best option, in terms of application security. Someone else may weigh-in about performance limitations; but if a user alters and submits their own query string through a javascript console and drops your entire table, performance won't really be a factor anymore will it?
We are in the process of splitting our db into several smaller ones. The schemas will be exactly the same and we will control which db the system connects to when the client logs in. I receive an error if I do not set a connection string in my nhibernate configuration. I do not want to create a factory for each db. Is it possible to have a session factory provide a Session that I can set the connection string before using it?
Have not used it but there is a method ChangedDatabase on the Session.Connection. Maybe that would work?
Maybe you can use NHibernate.Shards, in the NHcontrib repository