I've done DSN Less 2 different ways, but neither seem to have a way to specify a schema.
I tried specifying to schema like [schema]. but it doesn't work.
Any idea how to get it to link up?
You don't specify the schema in the connection string, but specify that schema in the table name (or view).
So, the default schema is "dbo".
So for table customers and schema "dbo", you use
dbo.Customers.
If the schema is sales, or other? then you go:
sales.Customers.
So the connection to the database is un-changed.
You don't have to (or can) specify the schema in the conneciton - you specifty it in the table name.
Of course the local table name can be ANY table name you want - and you are free to include or not the prefix like this
dbo_Customers
Sales_Contacts
But, you can could use
Customers
Contacts
In fact, in most cases, if you doing a migration from a standard Access data file back end to SQL server?
Then you of course will keep the client side (linked) table name as to what it was before, and the linked table name does not have any special meaning in regards to the schema used.
So only the table prefix (dbo.) is how you select/change/use a database schema, and this ONLY applies to the server side name you use when creating a table link. As noted the client side linked table can be any name you want, and it can "only" include the schema if YOU decide to adopt some naming convention.
So, you specify the schema by prefixing the server side table name when re-linking, or creating a table link.
I am creating tables in the GUI of postgreSQL, PgAdmin3. There is an element that seems to be specious in the naming of the tables. The following is my fragmented comprehension of postgreSQL (I could be wrong if I am, please rectify). I am inserting tables in the database using the ETL tool Talend.
When there is only one schema in the database: No reference to the schema is mandatory
select * from tablename
When there is more than one schema in the database: Reference to the schema is mandatory and the reference to the schema is required in quotes
select * from "schema".tablename
There is something new I drifted upon yesterday and I do not know what might be causing pgAdmin to do this:
select * from "schema"."tablename"
I am not oblivious of the part that referencing to the specific schema is mandatory when there is more than one schema present in the same database and in quotes but why does one need to have the table name in quotes as well.
We are in the process of developing an "API" for one of our products. This will allow the user to define which columns they wan't to return from their "queries" and we will build the needed SQL.
I know that you should always use parameterized queries to avoid SQL injection attacks. However is there any security risks when building a statement where the columns returned are defined by the users? Lets say we have the following api request. This is just an example to illustrate what I mean :)
/api/customers/getall?fields=Name,Phone,Email&where=Zip=1000
The SQL will be
SELECT Name, Phone, Email FROM Customers WHERE Zip = #Zip
I'm not thinking about just taking the fields parameter and building the SQL directly around that, it will probably be made into a list and returned with some default columns like Id and Modified.
What should you be aware of in this situation? And how would you protect against attacks?
-- Christian
Create a Stored Procedure
This will let you check the input Stings and you should be on the safe side.
See:
MSDN Create Stored Procedures
First, I do a query to get the fields of the selected table(s) from the INFORMATION_SCHEMA.COLUMNS metadata table.
Querying database metadata
The column names pulled from the database are safe to use. Then I compared the fields in the SELECT clause with the "safe fields list". If one of the selected fields isn't on the clean list, then remove it or don't run the generated SQL at all.
Part of a reporting toolkit we use for our development is configured to always use the same schema (say XYZZY).
However, certain customers have stored their data in a different schema PLUGH. Is there any way within DB2/z to alias the entire schema XYZZY to refer to the objects in schema PLUGH?
The reporting toolkit runs on top of ODBC using the DB2 Connect Enterprise Edition or Personal Edition 9.1 drivers.
I know I can set up individual aliases for tables and views but we have many hundreds of these database objects and it will be a serious pain to do the lot. It would be far easier to simply have DB2 auto-magically translate the whole schema.
Keep in mind we're not looking for being able to run with multiple schemas, we just want a way to redirect all requests for database objects to a single, differently named, schema.
Of course, if there's a way to get multiple schemas on a per-connection basis, that would be good as well. But I'm not helpful.
I am guessing that by DB/2 schema you mean the qualifying name in some two part object name. For
example, if a two
part table name is: PLUGH.SOME_TABLE_NAME. You want to do define XYZZY as an
alias name for PLUGH so the reporting program can refer to the table as XYZZY.SOME_TABLE_NAME.
I don't know how to directly do that (schema names don't take on aliases as far as I am aware).
The objection you have to defining individual alias names
using something like:
CREATE ALIAS XYZZY.SOME_TABLE_NAME FOR PLUGH.SOME_TABLE_NAME
is that there are hundreds of them to do making it a real pain. Have you thought about
using a SELECT against the DB/2 catalogue to generate CREATE ALIAS statements for
each of the objects you need to refer to? Something like:
SELECT 'CREATE ALIAS XYZZY.' || NAME || ' FOR PLUGH.' || NAME
FROM SYSIBM.SYSTABLES
WHERE CREATOR = 'PLUGH'
Capture the output into a file then execute it. Might be hundreds of commands,
but at least you didn't have to write them.
As the topic suggests I wish to be able to pass table names as parameters using .NET (doesn't matter which language really) and SQL Server.
I know how to do this for values, e.g. command.Parameters.AddWithValue("whatever", whatever) using #whatever in the query to denote the parameter. The thing is I am in a situation where I wish to be able to do this with other parts of the query such as column and table names.
This is not an ideal situation but it's one I have to use, it's not really prone to SQL injection as only someone using the code can set these table names and not the end-user. It is messy however.
So, is what I am asking possible?
EDIT: To make the point about SQL injection clear, the table names are only passed in by source code, depending on the situation. It is the developer who specifies this. The developer will have access to the database layer anyway, so the reason I am asking is not so much for security but just to make the code cleaner.
You cannot directly parameterize the table name. You can do it indirectly via sp_ExecuteSQL, but you might just as well build the (parameterized) TSQL in C# (concatenating the table-name but not the other values) and send it down as a command. You get the same security model (i.e. you need explicit SELECT etc, and assuming it isn't signed etc).
Also - be sure to white-list the table name.
I don't think I've ever seen this capability in any SQL dialect I've seen, but it's not an area of expertise.
I would suggest restricting the characters to A-Z, a-z, 0-9, '.', '_' and ' ' - and then use whatever the appropriate bracketing is for the database (e.g. [] for SQL Server, I believe) to wrap round the whole thing. Then just place it directly in the SQL.
It's not entirely clear what you meant about it not being a SQL injection risk - do you mean the names will be in source code and only in source code? If so, I agree that makes things better. You may not even need to do the bracketing automatically, if you trust your developers not to be cretins (deliberately or not).
You can pass the table name as a parameter like any other parameter. the key is you have to build a dynamic sql statement, which then you should consider if it's easier to build it in your app tier or in the procs.
create procedure myProc
#tableName nvarchar(50)
as
sp_executesql N'select * from ' + #tablename
fyi this code sample is from memory have a look at BOL for the proper syntax of sp_executesql.
Also this is highly sucesptible to SQL injection as you indicated is not an issue for you but anyone reading this should be very wary of accepting input from a user to generate their queries like this.
SQL query parameters can only take the place of a literal value. You cannot use a parameter for a table name, column name, list of values, or other SQL syntax. That's standard SQL behavior across all brands of database.
The only way to make the table name dynamic is to interpolate a variable into your SQL query before you prepare that string as a statement.
BTW, you're fooling yourself if you think this isn't a risk for SQL injection. If you interpolate the table name into the query dynamically, you need to use delimited identifiers around the table name, just as you would use quotes around a string literal that is interpolated from a variable.
The idea that it is not prone to SQL injection is misguided. It may be less prone to SQL injection from front end users, but it is still very much prone to SQL injection. Most attacks on databases come from inside the company being attacked, not from end users.
Employees may have grudges, they may be dishonest, they may be disgruntled, or they may just be not so bright and think that it's ok to bypass security to do whatever it is that THEY think should be done to the database.
Please see this post answer by user Vimvq1987:
MySqlParameter as TableName
Essentially you first check the table name against the schema, in which the table name is used in a parameterized fashion. Then if all is ok, the table name is legit.
Paraphrased basic idea is:
SELECT table_name
FROM information_schema.tables
WHERE table_schema = 'databasename'
AND table_name = #table;
cmd.Parameters.AddWithValue("#table",TableName);
If this returns ok with the table name, go ahead with your main query...
I would just check
select OBJECT_ID(#tablename)
the idea is to prevent injection you know it has to be table name this was if this returns a number then i would run the actual query,