Сan you help me to convert this Oracle rule to T-SQL.
SELECT CAST(SYS_CONTEXT('CLIENTCONTEXT', 'AccessSubject') AS NVARCHAR2(255)) AS AccessSubjectCode FROM DUAL
I would like to know how this will be in T-SQL : SYS_CONTEXT()
The SYS_CONTEXT('CLIENTCONTEXT', 'AccessSubject') call returns a value configured by the client application. See https://docs.oracle.com/cd/B28359_01/network.111/b28531/app_context.htm#DBSEG98209 for details.
The most similar feature in SQL Server is the CONTEXT_INFO() function. See https://msdn.microsoft.com/en-us/library/ms180125.aspx. However, in SQL Server the context can store just a single value, of maximum 128 bytes (as opposed to Oracle, where there are multiple contexts and you can store multiple named values in each context).
Related
I am working on a solution to compare Datasets from SAP HANA and Azure SQL Server to check consistency of data on SQL server.
Instead of getting all the fields from HANA and doing an "except",
I was thinking of evaluating and comparing a Checksum or Hashbytes on both systems.
However, the Hashvalues for same data is not matching.
Hash Values on SAP HANA
SELECT HASH_MD5(MANDT), HASH_SHA256(MANDT) from SLT_DECO100.MSKU where CHARG = 'UK2031RP' and WERKS = 'U72D'
0x25DAAD3D9E60B45043A70C4AB7D3B1C6
0x47DC540C94CEB704A23875C11273E16BB0B8A87AED84DE911F2133568115F254
Hash Values on SQL Server
select HASHBYTES('MD5', MANDT), HASHBYTES('SHA2_256', MANDT)
from consolidation.MSKU where CHARG = 'UK2031RP' and WERKS = 'U72D'
0xA4DC01E53D7E318EAB12E235758CFDC5
0x04BC92299F034949057D131F2290667DE4F97E016262874BA9703B1A72AE712A
Need support to understand and perform comparison
The hash values could be different based on algorithms what we are using.
Here in the below link comparing the data from two different environments of same tables by providing the pipe delimiters in query.
The pipe delimiters will separates the data from column to column then it gives the accurate results.
Check here for Compare Records Using Hash Values.
Note: More information for the below text in Microsoft Docs,
Algorithms (MD2, MD4, MD5, SHA & SHA1) are deprecated starting with SQL Server 2016 (13.x).
Use SHA2_256 or SHA2_512 instead. Older algorithms will continue working, but they will raise a deprecation event.
I am looking for the dynamic result set to be return from procedure as we have in SQL Server.
In the earlier version of Postgres there was not procedure till version 10, but now in 11 we do have procedures.
I tried with functions in the postgresql but we need to provide the return type for the functions. But I am looking for the result which is dynamic, I mean to say sometimes the results comes from different table with different columns list based on the conditions check.
As I saw some of the examples of procedures from EDB, Unable to find an example for retrieving data.
I use Firebird 2.5, and I want to retrieve the following values
Username:
I used SELECT rdb$get_context('SYSTEM', 'CURRENT_USER') FROM ...
Database name:
I used SELECT rdb$get_context('SYSTEM', 'DB_NAME') FROM ...
But for server name, I did not find any client API, do you know how can I retrieve the server name with a SELECT statement.
There is nothing built-in in Firebird to obtain the server host name (or host names, as a server can have multiple host names) through SQL.
The closest you can get is by requesting the isc_info_firebird_version information item through the isc_database_info API function. This returns version information that - if connecting through TCP/IP - includes a host name of the server.
But as your primary reason for this is to discern between environments in SQL, it might be better to look for a different solution. Some ideas:
Use an external table
You can create an external table to contain the environment information you need
In this example I just put in a short, fixed width name for the environment types, but you could include other information, just be aware the external table format is a binary format. When using CHAR it will look like a fixed width format, where values shorter than declared need to be padded with spaces.
You can follow these steps:
Configure ExternalFileAccess in firebird.conf (for this example, you'd need to set ExternalFileAccess = Restrict D:\data\DB\exttables).
You can then create a table as
create table environment
external file 'D:\data\DB\exttables\environment.dat' (
environment_type CHAR(3) CHARACTER SET ASCII NOT NULL
)
Next, create the file D:\data\DB\exttables\environment.dat and populate it with exactly three characters (eg TST for test, PRO for production, etc). You can also insert the value instead, the external table file will be created automatically. Inserting might be simpler if you want more columns, or data with varying length, etc. Just keep in mind it is binary, but using CHAR for all columns will make it look like text.
Do this for each environment, and make sure the file is read-only to avoid accidental inserts.
After this is done, you can obtain the environment information using
select environment_type
from environment
You can share the same file for multiple databases on the same host, and external files are - by default - not included in a gbak backup (they are only included if you apply the -convert backup option), so this would allow moving database between environments without dragging this information along.
Use an UDF or UDR
You can write an UDF (User-Defined Function) or UDR (User Defined Routine) in a suitable programming language to return the information you want and define this function in your database. Firebird can then call this function from SQL.
UDFs are considered deprecated, and you should use UDRs - introduced in Firebird 3 - instead if possible.
I have never written an UDF or UDR myself, so I can't describe it in detail.
In Legacy sql, we can do SELECT ABS(HASH('12345')) to get unique hash number of a value.
I am in process of converting legacy sql to standard sql in GBQ,
so wondering whats the best way to convert above function so that it gives me same value back as legacy sql.
We won't expose a function that returns the same values as in legacy SQL; it uses an undocumented implementation. The closest equivalent when using standard SQL is FARM_FINGERPRINT, which uses the open-source FarmHash library.
For the expression that you provided, you would instead use ABS(FARM_FINGERPRINT('12345')).
i have a DB2 data source and an Oracle 12c target.
The Oracle has a DB link to the DB2 defined which is working in general.
Now i have a huge table in the DB2 which has a timestamp column (lets call it ROW_CHANGED) for row changes. I want to retrieve rows which have changed after a particular time.
Running
SELECT * FROM lib.tbl WHERE ROW_CHANGED >'2016-08-01 10:00:00'
on the DB2 returns exactly 1 row after ca. 90 secs which is fine.
Now i try the same query from the Oracle via the db link:
SELECT * FROM lib.tbl#dblink_name WHERE ROW_CHANGED >TO_TIMESTAMP('2016-08-01 10:00:00')
This runs for hours and ends up in a timeout.
I read some Oracle docs and found distributed query optimization tips but most of them refer to joining a local to a remote table which is not my case.
In my desperation, i have tried the DRIVING_SITE hint, without effect.
Now i wonder when the WHERE part of the query will be evaluated. Since i have to use Oracle syntax and not DB2 syntax for the query, is it possible the Oracle will try to first copy the full table and apply the where clause afterwards? I did some research but did not find anything which would help me in this direction.
The ROW_CHANGED is a hidden column in the DB2, if that matters.
Thx for any hint in advance.
Update
Thanks#all for help. I'll share what did the trick for me.
First of all i have used TO_TIMESTAMP since the DB2 column is also Timestamp (not date) and i had expected to circumvent implicit conversions by this.
Without the explicit conversion i ran into ORA-28534: Heterogeneous Services preprocessing error and i have no hope of touching the DB config within reasonable time.
The explain plan btw did not bring much. It showed a FULL hint and no conversion on the predicates. Indeed it showed the ROW_CHANGED column as Date, i wonder why.
I have tried Justins suggestion to use a bind variable, however i got ORA-28534 again. Next thing i did was to wrap it into a pl/sql block (will run in a SP anyway later).
declare
v_tmstmp TIMESTAMP := 01.08.16 10:00:00;
begin
INSERT INTO ORAUSER.TMP_TBL (SRC_PK,ROW_CHANGED)
SELECT SRC_PK,ROW_CHANGED
FROM lib.tbl#dblink_name
WHERE ROW_CHANGED > v_tmstmp;
end;
This was executing in the same time as in DB2 itself. The date format is DD.MM.YY here since it is the default unfortunately.
When changing the variable assignment to
v_tmstmp TIMESTAMP := TO_TIMESTAMP('01.08.16 10:00:00','DD.MM.YY HH24:MI:SS');
I got the same problem as before.
Meanwhile the DB2 operators have created an index in the ROW_CHANGED column which i requested earlier that day. This has solved the problem in general it seems. Even my original query finishes in no time now.
If you are actually using an Oracle-specific conversion function like to_timestamp, that forces the predicate to be evaluated on the Oracle side. Oracle isn't going to know how to convert a built-in function like to_timestamp into an exactly equivalent function call in DB2.
If you used a bind variable, that would be more likely to get evaluated on the DB2 side. But that may be complicated by the data type mapping between different databases-- there may not be a perfect mapping between one engine's date and another engine's timestamp data type. If this was a numeric column, a bind variable would be almost certain to get pushed. In this case, it probably involves playing around a bit to figure out exactly what data type to use for your variable that works for your framework, Oracle, and DB2.
If using a bind variable doesn't work, you can force the predicate to be evaluated on the remote server using the dbms_hs_passthrough package. That lets you send a query verbatim to the remote server which allows you to do things like use functions defined in your DB2 database. That's a bit of overkill in this situation, hopefully, but it's nice to have the hammer as your backup if the simpler solution doesn't work quickly enough.