This answer on a question on SO says
... you can read a LONG from a remote database, but you can't read a CLOB
I did not find anything about this on the internet, is it true? Any documentation or citings for this will be helpful.
The answer is correct in a certain context, for simple select statements over a DB link, you'll get this error:
ORA-22992: cannot use LOB locators selected from remote tables.
From the errors manual:
Cause: A remote LOB column cannot be referenced.
Action: Remove references to LOBs in remote tables.
I also had trouble finding definitive documentation on this...but we just ran into the same issue in our data warehouse. However, there are several work-arounds available, pulling the data over or creating a view for example.
#Peter Ilfrich: Doesn't that throw an exception when trying to access any clobs over 4000 bytes?
This is a little more convaluted, but it means you can safely pull back small clobs (< 4000) over a dblink.
select dbms_lob.substr#<link>((select <columnName> from dual#<link>), 4000, 1)
from <table>#<link>
where dbms_lob.getlength#<link>((select <columnName> from dual#<link>)) <= 4000;
Reading a CLOB (or a BLOB) over a dblink is possible with this PL/SQL package:
https://github.com/HowdPrescott/Lob_Over_DBLink
If both DB schemes are in the same Oracle instance, you can use the following workaround:
select (select <columnName> from dual) <columnName> from <table>#<link>
This will return you the same as if you would access a local LOB column.
Oracle 12.2 finally added support for distributed LOBs. We can now read data types like CLOB and XMLType over database links without any workarounds.
I had the same trouble yesterday. This is My solution: create a romote view on the romote table, when comes the CLOB cols, use to_char(),such as to_char(col2). Then you can select data from the view. It may not be a good solution, but it works.
You can create a Materialized View from remote table and then use from that for your needs
https://webcache.googleusercontent.com/search?q=cache:LG2eG1gThV8J:https://community.oracle.com/thread/471047%3Fstart%3D0%26tstart%3D0+&cd=2&hl=en&ct=clnk&gl=ir
When your table from dblink it's an Oracle Big Data External table (in my case an external table over a Hive table), you need to create a materialized view over it and use that materialized view with the above mentioned pl/sql package: https://github.com/HowdPrescott/Lob_Over_DBLink
Works for clobs > 4000.
Tested only for CLOB!
Related
I was given a task to develop a report that would present the following details (as separate columns in ALV):
1) Name of the DB table (like MSEG, EKPO etc.)
2) Size of the DB table in megabytes
3) Number of records
4) Number of read requests performed on the table
5) Number of write requests performed on the table
There are DB* tables that contain such kind of info. Specifically I am referring to DB6PMHST and DB6HISTBS. When I try to view them via SE11 or SE16, system reports that these tables do not hold any records. I tried all three development, testing and production landscapes.
Please may you provide a guidance on what I am doing wrong? Maybe there are some other system tables that would contain the necessary info?
P.S. I tried to debug ST04 transaction in order to see the tables from which the report selects data, but wasn't able to find those lines of the source code.
I would deeply appreciate your kind assistance.
P.S.S. Checked the table MSSDBSTATT - it is empty as well (our enterprise uses MS SQL Database)
Go to SE38 and run this report RSTABLESIZE, enter table ID and see the magic.
The number of reads and writes on a table is a subject specific to the type of database (MSSQL) -> please tag your question accordingly.
If you get an answer by an MSSQL expert, which says that the data is stored in some MSSQL tables, then you cannot query those tables using "Open SQL" but you may query them using "native SQL" (i.e. EXEC SQL or ADBC for instance).
I have looked and found some instances there something similar is being done for websites etc....
I have a SQL table that I am accessing in FileMaker Pro (Through ESS) via an ODBC connection to the SQL database and I have everything I need except there is one field(LNL_BLOB) in one table (duo.MMOBJS) which is an image "(image, null)" which cannot be accessed via the ODBC connection.
What I am hopping to accomplish is find a way that when an image is placed in the field, it is ALSO converted to Base64 in another field in the same table. Also, the database creator has a "View" (Foreign Concept to us Filemaker Developers) with this same data called "dbo.VW_BLOB_IMAGES" if that is helpful.
If there is a field with Base64 text, within FileMaker I can decode it to get the image.
What thoughts do you all have? Is there and even better way?
NOTE: I am using many tables and lots of the data in the app that I have made, this image is not the only reason I have created the ODBC connection.
Table
View
Well, one way to get base64 out of SQL would be to trick the XML engine in SQL to convert your column to base64, then strip out the XML:
SELECT SUBSTRING(Q.Base64Data, 7, LEN(Q.Base64Data)-9)
FROM (SELECT
(
SELECT LNL_BLOB AS B
FROM duo.MMOBJS
FOR XML raw('r'), BINARY BASE64
) AS [Base64Data]) AS [Q]
You'd probably want to add that to your select statement or a view, rather than add it to the table; but, you could write a trigger that would maintain the field using that definition.
Basically I have a two databases on SQL Developer. I want to take the table data FOR A PARTICULAR RECORD from one database and copy it to another database's table. What should be the query? I don't want to use a restore to avoid data loss... Any ideas?
I got a query from google:
INSERT INTO dbo.ELLIPSE_PFPI.T_ANTENNE
(COLUMNS)
SELECT COLUMNS_IN_SAME_ORDER FROM dbo.ELLIPSE_PFPI.T_ANTENNE
What should be written in the query instead of dbo?
Try this
I havent tested it but i think it works
select * into [databaseTo].dbo.tablename from [databaseFrom].dbo.tablename
Hey StackOverflow community,
My question is as follows:
I have a table, say USER_ADDR with a bunch of columns in one database, say DB001
I need to copy the contents of this table(based on a criteria) to a similar table USER_ADDR (same name, yes) in another database DB002 with a different userID and pwd.
I need to do this in a stored procedure that will be executed using a .net framework.
I tried this:
INSERT INTO "DB002".USER_ADDR (--column names--)
SELECT *
FROM "DB001".USER_ADDR
WHERE ID = "APPLICATION_NO_IN";
I get:
0: Error occurred: [IBM][DB2/NT64] SQL0204N "DB002.USER_ADDR" is an undefined name. LINE NUMBER=15. SQLSTATE=42704 : -204: IBM.Data.DB2: 42704
What am I doing wrong?
Thanks in advance
Vashist
i'm deleting my other answer after seeing the additional info about your use case. Load is mainly for bulk loads of large numbers of records.
in this case i'd recommend you do something like open connection1 in .Net to your data source, select the data and hold it in a .Net DataTable. If required, you can do that select in a stored proc that returns either individual column values for a single row or return a cursor (rowset) that contains all the columns (and rows). Then in .Net open connection2 and insert the data from the DataTable to your destination. Again, that can be done with a stored proc.
Another approach is using an external script that connects to both databases.
From just one database is not possible, at least you use, as already mentioned, Information integration (federation) or by exporting the data and then loading it.
I have a SQL Server instance that I've added a linked server to another SQL instance. The table I'm accessing on the linked server contains spatial types. When I try to query the table I receive an error:
Objects exposing columns with CLR types are not allowed in distributed
queries. Please use a pass-through query to access remote object.
If I use OPENQUERY with the same query I get another error:
A severe error occurred on the current command. The results, if any,
should be discarded.
Is there any way to query tables that contain spatial types via linked servers?
One way to work around this is to pass spatial data as NVARCHAR(MAX)
select go=geometry::STGeomFromText(go,0)
from openquery([other\instance],
'select go=convert(nvarchar(max),go) from tempdb.dbo.geom')
note: go is a column name, short for geometry-object
Or using the function instead of explicit cast
select go=geometry::STGeomFromText(go,0)
from openquery([other\instance],
'select go=go.STAsText() from tempdb.dbo.geom')
I came across the same problem, but accepted solution wasn't an option in my case, due to many applications that couldn't be changed to expect a totally different query.
Instead, I think I found a way to cheat the system. On local server run:
CREATE VIEW stage_table
AS
SELECT *
FROM OPENQUERY([REMOTESERVER],'SELECT * FROM [REMOTEDB].[SCHEMA].TARGET_TABLE');
GO
CREATE SYNONYM TARGET_TABLE FOR stage_table;
GO
Voila, you can now simply use
SELECT * FROM TARGET_TABLE;
Which is probably what your applications expect.
Tried the above scenario with local server: SQLEXPRESS 2008 R2, and remote server SQL EXPRESS 2014.
I have another workaround. It doesn't apply to the OP's question since they were trying to select the spatial data. Even if you are not selecting the columns containing spatial data, you'll still get this error. So if you need to query such a table, and do not need to retrieve the spatial data, then you could create a view for the table (selecting only the columns you need, excluding the spatial data columns), then query against that view instead.