We have a Business Objects X14 universe and we have 2 oracle database schemas (BoDB, BoDB_CONNECT)
BoDB_CONNECT has to execute the queries using the BoDB schema.
I dont have password for BoDB schema.
So, basically I want to login with BoDB_CONNECT username and execute the reports using BoDB schema (by appending BoDB.TABLENAME).
But while I am creating the connection there is no separate schemaname in the Universe. It just have the username and password.
I dont want to hardcode the ownername of every table with BoDB. Is there any way to dynamically do this?
First, you have to be given access to the tables or nothing will work. That is, BoDB_CONNECT needs to have SELECT permissions to all of the tables in the BoDB schema that will be referenced in the universe.
Once that is done, you have a few options to implement your requirement. The most straightforward way is to simply include the schema owner with the table name. This happens automatically when you drag in a table to your model in UDT or IDT, and is the recommended solution.
You can also easily switch the owners, if, for example, the tables are moved to a new schema. Select all of the tables to move, and right-click. In UDT, select "Rename Table" and in IDT select "Change Qualifier/Owner". You can then set the new owner name and that will be applied to all selected tables.
If, for some reason, you won't want the schema name associated with the table, there are two options:
Create a private synonym in the BoDB_CONNECT schema for each table to be referenced in BoDB (ex. create synonym foo for bodb.foo). Thus, the universe will just have a reference to foo. Note, however, that BI4.1 does not currently support private synonyms in UDT/IDT. If you create objects that reference private synonyms, they will work correctly in WebI, but they will not parse in UDT/IDT. I believe this is a bug (since it worked in all prior versions), and I have a support case open with SAP currently.
Switch the default schema. You can change the BEGIN_SQL parameter to set the default schema. In UDT this is done via File->Parameters-Parameter tab; in IDT it's Data Foundation->Properties->Parameters. In either case, you'd set the value of BEGIN_SQL to ALTER SESSION SET CURRENT_SCHEMA=bodb. This statement will be executed at the start of each query session, so references to foo will resolve to bodb.foo. Note, however, that this does not apply to actions within IDT/UDT itself; so you will get parse errors on objects that don't have an owner specified, but the queries will work in WebI.
Related
I have a typical Access front-end with SQL Server back-end. I created some views in SQL Server and linked to them in Access. When I use "CREATE INDEX index_name ON view_name (field_name)" it creates a primary key even though I have not specified it to do so (and do not want it to do so). Why is that? and how can I create a non-primary key index?
How this works?
Any view, any linked table, in fact ANYTHING you hit, use, consume from SQLServer?
All indexing is setup 100% in SQLServer. The Access client side does not, cannot, and WILL not create any kind of index for you.
The create index command to specify and setup a primary key? It does not really create an index in Access but ONLY SETS and TELLS Access what PK to use.
In fact, when you link to a view, you are prompted to select the PK when linking to a view.
SQLServer views DO NOT have the concept or even a setting that tells you or EVEN LETS you specify the PK column. Part of the reason for this is in fact that a view can consist of more than one table - so which table now is to define the primary key. And in fact if your view has a join with say 5 tables? Then in fact that view has 5 different primary keys from 5 different tables).
So, when you link to a view in access, you will note this prompt:
If you don't select a column for the pk?
Then you have no PK set. However, you can use VBA to TELL ACCESS what row to be the PK setting.
So, say in above I did not select a PK when linking with the GUI. Or say I am using code to link to a view?
Then in code to set the PK value, I would and could and should execute the following command:
CurrentDb.Execute "CREATE UNIQUE INDEX IXPK ON dbo_ViewHotelsTest (ID) WITH PRIMARY"
AGAIN: Note above comments. The create unique index DOES NOT create an index in Access. Nor does it create an index on SQLServer. That command is how you can tell Access which column is to be seen and treated as the PK.
So, above command?
In plain English:
Please Mr. Access, will you set the PK column and we are using the above
command to do this.
In other words, there is no other command in code to "tell" Access what the PK is supposed to be, so the DDL sql create index command is used. But I STRESS AGAIN THIS does NOT really create an index, but ONLY tell Access what column to use as the PK.
This command results in the SAME and IDENTICAL results if you select a PK during a linking of a view.
If you want to create an index in SQLServer? Then go to SQLServer, and create your index(es) in SQLServer.
FYI:
As a further explanation, in 99% of cases you NEVER want, nor need, or even should even create an index on a view on the SQLServer side of things.
In EVERY case, if the base table used for the source of the view has an index that can be used, it WILL IN ALL cases be used if you build an on-the-fly query, build a SQLServer side view, or even create a sql stored procedure. IN ALL cases, a simple create of an index on the base source table (using SQLServer tools) will suffice, and in ALL cases, include views, and including linked view from Access will automatic use ANY and ALL existing indexes on the base table from SQLServer.
So, not only is there zero requirements to EVER try and create an index in Access on linked tables (or linked views), but in fact it not even possible. Of course the create index command DOES need to be used to set the PK column when linking to a view.
If you link to table, then Access can figure out which column is the PK, and will set this for you. But SQLServer does not have a setting, nor even the concept of a PK column for a view, and thus you have to select the PK during linking using the GUI, or as noted, you can in code execute the above command that tells access which column to use as the PK, and as noted, that command does not in fact even create an index, but that command is ONLY to tell Access client side which column to see/use as the PK.
You can for views that don't require you to "update" the data. So, a linked view without you selecting (or better said "setting") the PK column will be read only.
So, if you using the view for a combo box, or say just a report? Then you don't care, and don't need to set the PK for that view, and it will be "read only". So this means that you ONLY need to set the PK column for a view if you need to update that view (say in place of updating the base table that the view is based on).
So, in summary:
that create index command does not actually create an index.
That create index command is ONLY required if you need a linked view that allows Access client side to update such views. Without the setting, then the linked view will be read only. So the purpose, the act, the role, the "thing" that create index does on the linked view? It is ONLY to tell Access what column is to be used for the PK - it does not actually create an index anywhere - including NOT creating one in Access client side. (So, ONLY purpose is for TELLING access which column to use for the PK. Can't really say why they use that command that way but best guess was no other way existed to tell Access what column to use for the PK - so we use that command).
If you use the linked table manager, and re-fresh the table links? Access WILL remember the PK settings for a view. However, if during linking you change the database that the linked tables point to? Then the PK settings in views will be lost during that re-linking process. (and then you have to re-execute those commands to re-tell Access which column in the linked view is to be seen/used as PK column.
You don't need to ever create an index client side for Access in regards to linked tables, or views - all indexing is automatic, and if an index exists on the server table, it will and can be used.
So, create index command is HOW you setup a PK column for linked views. In all other cases (linked tables - but not a view), then that command is not required, and ANY and all existing indexes that exist and were created on the server side table will be used (and thus no need to try or create an index in Access, since all such indexes are handled by the server side - Access has no say, nor even control over how SQLServer uses indexes). But, a correct use of index on a SQLServer table will automatically be used by Access in the requests it makes to SQLServer. But that "job" of indexing is 100% managed by the server - not Access.
This is something I can't seem to find information on.
Let's say I have a table users, and for security purposes, I want any SQL query to only executable if a reference to the id columns is made.
E.g. this should NOT work:
UPDATE users SET source="google" WHERE created_time < 20210303;
The above update statement is syntactically valid, but because it isn't making a reference to the id column, it should not be executable.
Only the below would be executable:
UPDATE users SET source="google" WHERE id in (45,89,318);
Is there any way to enforce this from the MySQL server's end?
I think the only way you can really do what you want is to use a stored procedure, where you pass in the ids and to the update there. You would set up the security as:
Turn off updates to the underlying table for all-but-one user.
Run the stored procedure as the user with permissions to modify the table (using DEFINER).
This will be cumbersome because you will need to pass in all the values in the table.
You can come close with safe update mode. However, that also allows LIMIT as well as key comparisons, so that is not sufficient for your purposes.
Note: This sort of issue is usually handled in another way. Most users would not have permissions to modify such a table. Then "special" users who do would be assumed to be more knowledgable and careful about changes. If the data is sensitive, then the changes would be logged, so it would be (relatively) easy to undo changes that have been made.
Is there any way to detect when an ALTER TABLE statement is executed in MySQL? For example, if the following statement were executed on some_table, is there any way to detect that the column name changed from column_name_a to column_name_b and log it in another table in the DB?
ALTER TABLE `some_table`
CHANGE COLUMN `column_name_a` `column_name_b` VARCHAR(255) NULL DEFAULT NULL;
Thanks.
To my knowledge it is unfortunately not possible to put triggers on the INFORMATION_SCHEMA tables, since they are strictly spoken views and triggers can't be made to work on views. If triggers would be possible on the INFORMATION SCHEMA, then you could have a trigger on updates of the INFORMATION_SCHEMA.COLUMNS table to identify name changes.
However, what you can do is one of the following things:
option 1) Maintain a real table with all column names. Then create a function that checks for a discrepancy between the INFORMATION_SCHEMA.COLUMNS table abd your table. If there is one, you know the name has changed. You need to copy over the new name to your column name table and do whatever else you wanted to do upon name change.
The function to check for discrepancies then must be run periodically via the mysql scheduler in order to detect name changes as quickly as possible. Note that this is not a real time solution. There will be a lag between the ÀLTER TABLE command and its detection. If this is unacceptable in your scenario you need to go with
option 2) Do not call ÀLTER TABLE directly, but wrap it in a function. Within this function you can also call other functions to achieve what you need to achieve. If may be worth while to formulate the needed steps in a higher programming language that you use to drive your application. If this is not possible, you will be limited to the possibilities that are offered in functions/procedures in the mysql environment.
Sorry to not have a simpler way of doing this for you.
Finally reached data migration part of my Project and now trying to move data from MySQL to SQL Server.
SQL Server has new schema (mapping is not always one to one).
I am trying to use SSIS for the conversion, which I started learning today morning.
We have customer and customer location table in MySQL and equivalent table in SQL Server. In SQL server all my tables now have surrogate key column (GUID) and I am creating the same in Script Component.
Also note that I do have a primary key in current mysql tables.
What I am looking for is how I can add child records to customer location table with newly created guid as parent key.
I see that SSIS have Foreach loop container, is this of any use here.
if not another possibility that I can think of is create two Data Flow Task and [somehow] just before the master data is sent to Destination Component [Table] on primary dataflow task , add a variable with newly created GUID and another with old PrimaryID, which will be used to create source for DataTask Flow for child records.
May be to simplyfy , this can also be done once datatask for master is complete and then datatask for child reads this master data and inserts child records from MySQL to SQL Server table. This would though mean that I have to load all my parent table records back into memory.
I know this is all too confusing and it is mainly because I am very confused :-(, to bear with me and if you want more information let me know.
I have been through may links that i found through google search but none of them really explains( or I was not able to uderstand) how the process is carried out.
Please advise
regards,
Mar
** Edit 1**
after further searching and refining key words i found this link in SO and going through it to see if it can be used in my scenario
How to load parent child data found in EDI 823 lockbox file using SSIS?
OK here is what I would do. Put the my sql data into staging tables in sql server that have identity columns set up and an extra column for the eventual GUID which will start out as null. Now your records have a primary key.
Next comes the sneaky trick. Pick a required field (we use last_name) and instead of the real data insert the value form the id field in the staging table. Now you havea record that has both the guid and the id in it. Update the guid field in the staging table by joing to it on the ID and the required field you picked out. Now update the last_name field with the real data.
To avoid the sneaky trick and if this is only a onetime upload, add a column to your tables that contains the staging table id. Again you can use this to get the guid for inserting to related tables. Then when you are done, drop the extra column.
You are aware that there are performance issues involved with using GUIDs? Make sure not to make them the clustered index (as the PK they will be by default unless you specify differntly) and use newsequentialid() to populate them. Why are you using GUIDs? If an identity would work, it is usually better to use it.
I need the sample program in Java for keeping the history of table if user inserted, updated and deleted on that table. Can anybody help in this?
Thanks in advance.
If you are working with Hibernate you can use Envers to solve this problem.
You have two options for this:
Let the database handle this automatically using triggers. I don't know what database you're using but all of them support triggers that you can use for this.
Write code in your program that does something similar when inserting, updating and deleting a user.
Personally, I prefer the first option. It probably requires less maintenance. There may be multiple places where you update a user, all those places need the code to update the other table. Besides, in the database you have more options for specifying required values and integrity constraints.
Well, we normally have our own history tables which (mostly) look like the original table. Since most of our tables already have the creation date, modification date and the respective users, all we need to do is copy the dataset from the live table to the history table with a creation date of now().
We're using Hibernate so this could be done in an interceptor, but there may be other options as well, e.g. some database trigger executing a script, etc.
How is this a Java question?
This should be moved in Database section.
You need to create a history table. Then create database triggers on the original table for "create or replace trigger before insert or update or delete on table for each row ...."
I think this can be achieved by creating a trigger in the sql-server.
you can create the TRIGGER as follows:
Syntax:
CREATE TRIGGER trigger_name
{BEFORE | AFTER } {INSERT | UPDATE |
DELETE } ON table_name FOR EACH ROW
triggered_statement
you'll have to create 2 triggers one for before the operation is performed and another after the operation is performed.
otherwise it can be achieved through code also but it would be a bit tedious for the code to handle in case of batch processes.
You should try using triggers. You can have a separate table (exact replica of your table of which you need to maintain history) .
This table will then be updated by trigger after every insert/update/delete on your main table.
Then you can write your java code to get these changes from the second history table.
I think you can use the redo log of your underlying database to keep track of the operation performed. Is there any particular reason to go for the program?
You could try creating say a List of the objects from the table (Assuming you have objects for the data). Which will allow you to loop through the list and compare to the current data in the table? You will then be able to see if any changes occurred.
You can even create another list with a object that contains an enumerator that gives you the action (DELETE, UPDATE, CREATE) along with the new data.
Haven't done this before, just a idea.
Like #Ashish mentioned, triggers can be used to insert into a seperate table - this is commonly referred as Audit-Trail table or audit log table.
Below are columns generally defined in such audit trail table : 'Action' (insert,update,delete) , tablename (table into which it was inserted/deleted/updated), key (primary key of that table on need basis) , timestamp (the time at which this action was done)
It is better to audit-log after the entire transaction is through. If not, in case of exception being passed back to code-side, seperate call to update audit tables will be needed. Hope this helps.
If you are talking about db tables you may use either triggers in db or add some extra code within your application - probably using aspects. If you are using JPA you may use entity listeners or perform some extra logic adding some aspect to your DAO object and apply specific aspect to all DAOs which perform CRUD on entities that needs to sustain historical data. If your DAO object is stateless bean you may use Interceptor to achive that in other case use java proxy functionality, cglib or other lib that may provide aspect functionality for you. If you are using Spring instead of EJB you may advise your DAOs within application context config file.
Triggers are not suggestable, when I stored my audit data in file else I didn't use the database...my suggestion is create table "AUDIT" and write java code with help of servlets and store the data in file or DB or another DB also ...