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.
Related
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 working w the Teradata SQL Assistant. What I am trying to do, is to list all databases visible in the 'Database Explorer'. At first, I have tried simple query:
select DatabaseName from DBC.Databases;
but this returned thousands of databases I don't even have an access to. The DBC.Databases table seems not to have any field allowing me to filter results to only visible databases, or I am just unable to find it. And I am almost sure there is no such field in any table like '%database%'.
Is there any way to list those visible databases with SQL query?
Never use a system view without a trailing V or VX, those are old legacy views which will truncate object names over 30 characters.
In your case you need to switch to dbc.DatabasesVX, the X indicates that all objects where you don't have any access right are filtered automatically. But this might still return more databases than Database Explorer where you can add databases to the list manually.
EDITED for clarity:
I've created a table in DB2 using SQL.
I have now realized that I did not know the record format for the physical file created and need a Logical File to define keys to use in the RPG code. How can I accomplish this using SQL rather than DDS?
This was what I wanted to ask, really, now that I know a lot more on the subject.
There's really no difference between a PF created with DDS and a table created with SQL DDL.
Both methods result in a *FILE object with an attribute of PF.
The resulting object from either method can be used with SQL or with RPG record level access (RLA).
You can create DDS LF's or SQL views/indexes over a DDS created PF or an SQL DDL created table.
IBM provides tools to generate SQL DDL for a DDS created object, but not the other way around. You might be able to find a 3rd party tool designed to generate DDS if you lose your DDS source.
Best practice now-a-days is to use SQL DDL; as many recent enhancements to the DB are not available when using DDS.
If you think you need to use DDS for compatibly with RPG for instance, you are incorrect. All you need to do is take advantage of IBM i specific keywords.
Instead of
create table my_long_table_name (
my_long_column_name char(10)
);
Use
create table my_long_table_name
for system name mytable (
my_long_column_name
for mycol char(10)
) rcdfmt mytabler;
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.
Earlier I had asked the question:
Where (or how) should I define the schema in a select statement when using PostgreSQL?
The answer I accepted was to modify the search_path for the connecting user so that the schema need not be specified in the SQL. However, now I wonder if I should always specify the schema in SQL rather than allow the schema to be automatically inferred by the search path. This seems like it would be a safer approach and would be more portable to other databases.
This question is different than the previous one in that I want to know what the best practices are for defining the schema in SQL, rather than how it can be done.
Should the schema always be explicitly defined in the SQL statement?
** Note: I would not hard code the schema name but would allow it to be configurable through the Web.config file so that the schema could change from one installation to another. **
It's a bad practice to hardcode schema into SQL statements.
You should keep it in the application settings and issue SET search_path after connecting to the database.
If your application is used by multiple users with their own schemas, your life will be much easier if you don't hardcode schema name into SQL.
In other words,
string query = "SELECT * FROM " + ConfigurationManager.AppSettings.Get("schema") + ".table";
is a bad way;
SQLCommand("SET search_path = " + ConfigurationManager.AppSettings.Get("schema"), connection).ExecuteNonQuery();
string query = "SELECT * FROM table";
is a good way.
Let's see - in the DB of the app I maintain there are around a dozen schemas. What would be the order if I put them in "search_path"? And would I put in the schema names (not the tables name and not the fully-qualified table names) in the configuration?
As you have guessed by now I do not use "search_path". But maybe you could store the fully-qualified table names in the configuration in case you ever change you mind about the names of the schemas or the tables themselves.