For a query which looks something like
select * from cus_query.ca_activity_vw#drifter
I imagine cus_query is the schema and the view's name is ca_activity_vw. But what is drifter ?
I quote the Oracle documentation:
If the identifier names an object on a remote database, you must reference it with its remote name. The syntax is:
simple_identifier_name#link_to_remote_database
If the identifier is declared in a PL/SQL unit on a remote database, you must reference it with its qualified remote name. The syntax is:
unit_name.simple_identifier_name#link_to_remote_database
From this page : http://docs.oracle.com/cd/E11882_01/appdev.112/e25519/fundamentals.htm#LNPLS99945
drifter is a so-called database link - it allows to transparently query tables that reside on a different database (usually Oracle, but possibly some other RDBMS, e.g. via Database gateway).
To see the definition for the database link, you can use this query (this requires DBA privileges):
select * from dba_db_links
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'm attempting to connect to DB2 through VBA. I have a connection established through the ODBC provider.
Here's the string of my command text looks like:
strCmd = "INSERT INTO mySchema.myTable (Text) VALUES ('Test')"
When I run this, I get the following runtime error:
[IBM][CLI Driver][DB2/NT64] SQL0204N "MYSCHEMA.MYTABLE" is an undefined name. SQLSTATE=42704
I have validated and verified that the schema and table exist in DB2. I have validated (by using another tool - IBM Data Studio - that the credentials have access and authority to write to this table.
Is my syntax wrong? Is there something I'm missing? If I don't add the "MYSCHEMA." in front of the table name, it presumes I want the "ADMIN" schema, which I don't (it doesn't even exist).
How do I successfully execute an insert command to DB2 LUW?
This is frequently asked.
Db2 automatically folds unquoted object names into uppercase.
This makes programming easier because being forced to quote objects is not so friendly.
It means that "myTable"."mySchema" is a different object than MYTABLE.MYSCHEMA.
So in general it is easier to configure your toolset to not quote object names when creating the objects, and so allow them to be folded to uppercase. It also allows subsequent queries to avoid having to quote table names and column names.
But sometimes you don't have a choice.
I have a copy of a query from a view (by filtering) and when i tried to excute it, it throws an error message that says "invalid object name 'bla bla'".
How can i fix it?
I am using windows 7(ultimate) os and sql server 2005 express.
You may be executing the query in the wrong database. If you are running it manually in SSMS, use the 'use' statement or the 'available databases' drop down list to select the correct db.
Or fully qualify the name of the object you are accessing (db_name.owner.object_name).
Or, as rlb.usa suggests, maybe the object just doesn't exist. (check your spelling...)
It can happen two ways:
You have table, procedure, or function name(s) that do not exist.
You can fix this by verifying the object does indeed exist. Check this one first. Is the spelling correct? Is the schema correct? (dbo.mytable != user.mytable)
SQL wants you to use "qualified" names.
You can fix this by putting use mydatabasename; at the top of your query, before the query itself. If it doesn't like that one, you can then try the longer method of using qualified names by prefixing all of your tables, functions, and procedures as databasename.schema.object .
I have a SqlServer db that I would like to port to MySQL. What's the best way to to this. Things that need to be ported are:
Tables (and data)
FileStream → MySQL equivalent?
Stored Procedures
Functions
Data types are relatively similar.
There is no equivalent to FileStream in MySQL - the files must either be stored as BLOBs, or on the file system while the path is stored in the database.
Migrating away from TSQL means:
There's no WITH clause in MySQL - it will have to converted into a derived table/inline view
There's no TOP syntax - these have to be converted to use LIMIT
There's no ranking/analytic functionality in MySQL - can't use ROW_NUMBER, RANK, DENSE_RANK or NTILE. See this article for alternatives.
MySQL views have notoriously limited functionality:
The SELECT statement cannot contain a subquery in the FROM clause.
The SELECT statement cannot refer to system or user variables.
Within a stored program, the definition cannot refer to program parameters or local variables.
The SELECT statement cannot refer to prepared statement parameters.
Any table or view referred to in the definition must exist. However, after a view has been created, it is possible to drop a table or view that the definition refers to. In this case, use of the view results in an error. To check a view definition for problems of this kind, use the CHECK TABLE statement.
The definition cannot refer to a TEMPORARY table, and you cannot create a TEMPORARY view.
Any tables named in the view definition must exist at definition time.
You cannot associate a trigger with a view.
As of MySQL 5.0.52, aliases for column names in the SELECT statement are checked against the maximum column length of 64 characters (not the maximum alias length of 256 characters).
Dynamic SQL will have to be converted to use MySQL's Prepared Statement syntax
A guide/article with some useful tips is available on the official MySQL dev site.
This is not for the faint of heart. Here is an article that explains what you are in for:
http://searchenterpriselinux.techtarget.com/news/column/0,294698,sid39_gci1187176,00.html
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.