Tag Info

New answers tagged

4

I think as a DBA you will inevitably lose the fight to keep hands out of your database. Having said that I think we owe it to our customers to try and provide a product that they can use. There are dangers and pitfalls of even read-only access that any DBA should be aware of: You admitted that you are working with large record counts in your tables. What ...


0

Be happy that your users seem to be going to use SQL to do the analysis, instead of pumping to excel. Make sure you have separated tasks and don't give privs to update the source data. Resource manager is your friend to prevent runaway queries. give them resources that they need, make sure other users don't get pushed out.


0

I think there is no problem, but you need to take care about data. For example, you can grant them privileges to create tables and procedures for their needs in theirs schemas, and privileges to select data from another schemas, but not to grant privileges on insert/update/delete. If they don't have privileges on update and delete data in main tables, ...


0

Maybe you need something like this? create or replace procedure p1 is begin select ... into ... from ... where ...; exception when no_data_found then ... raise_application_error(-20100, 'Something not found'); when others then ... end; create or replace procedure p2 is something_not_found exception; pragma ...


0

This might be over simplifying it, but could you use an IF *some variable* IS NOT NULL block around the call to the extra procedure? As in, "check to see if the variable I just wrote to is null, if not, do more work, if it is, specifically call my custom error package? If you've built your own exception handler (and kudos to you for not falling into the ...


1

There are a variety of approaches you could take. You should pick the one you feel is most suitable for your application. Include no WHEN OTHERS exception handlers and let the raw Oracle errors propagate to your users. Include WHEN OTHERS exception handlers in the top-level blocks. Include WHEN OTHERS exception handlers in all/most blocks The first ...


1

There are several ways to do this. One would be to use a pipelined function to return the additional row when the day spanning condition is detected. Another way is to duplicate the rows and then eliminate the ones that don't need to be duplicated and adjust the times for those that do. Here is an example: SELECT Case When TwoRowsNeeded = 1 And ...


0

There seems to be a combination of more than one problem at work here. First of all the pseudo-record :NEW is not available in a delete-trigger. You can only access the values of the deleted row via the pseudo-record :OLD. Hence the second call getlong ('XXX', 'yyy', :NEW.ROWID) will not make much sense. Secondly you pass a row-ID to the procedure getlong ...


0

ORA-06512 is a catch all for PL/SQL errors. The one you need to be concerned about is the ORA-01410 (more than likely a cause/effect here). What is your DB version? Run this: select * from v$database_block_corruption If this is a corporate database I highly recommend engaging your DBA immediately.


0

Sounds like a job for a database trigger. Assuming the StartDate and EndDate are static (the values remain the same for a particular row always), a trigger would be fairly simple. If the EndDate could be updated after the row is created, it could still be done but would be more involved. This would handle where just one additional row would need to be ...



Top 50 recent answers are included