We have a C++ legacy application that connects to an Oracle 11g database. The application uses Microsoft Data Access Objects (DAO) library to allow record browsing and modification. We also have some triggers on tables to track row updates and insertions.
The problem is that the triggers don't fire for the CLOB columns that we have in our tables. It gets fired for other columns but for this one CLOB column, it neither fires during update nor during delete. I've added the trigger for all three: UPDATE, INSERT and DELETE.
Is there some option that manages triggers for CLOBs? Or some other setting that might be affecting this? Any ideas where should I look for a solution?
I found a possible explanation to this non-firing trigger:
Your trigger actually works -- WHEN it is fired!
The problem is -- you are NOT updating the table when you set the lob value. You might be modifying the lob contents but -- and this is key -- you are NOT modifying the lob locator in the table itself. The row values of the table are not changing, the trigger does NOT fire for the dbms_lob.copy (or write, or trim, or append, or ...)
I think the solution proposed here at askTom requires to have a specific procedure but I haven't quite understand it.
Related
In maximo, can we delete a work order? The select action menu gives me
BMXAA4612E - Cannot delete because it is, or had at one time been approved.
I have created numerous test work orders and it is getting difficult to track new work orders.
Short Answer: You can't.
Standard Maximo will not let you delete it past a certain point. It keeps this data around for a sort of auditing (and because there could be a lot of dependencies to undo).
Bad Answer: With some database queries. You can of course delete about anything if you start modifying Maximo's underlying database directly. The Work Order object has a number of related tables though, so make sure you delete all referenced data from those as well. And there might be other places you need to update too, like a PM due date, depending on the situation.
In a normal Maximo environment, it is very common to have a lot of open work orders at any given time. You are going to need to develop ways to handle the fluff. Closing your old test work orders helps, because Maximo filters out closed work orders by default. Standard filters with some specialized data and saved queries are some other options.
Clear attribute: FIRSTAPPRSTATUS
update woactivity set FIRSTAPPRSTATUS = null
where ;
Then deleting should be possible
--> However it is not (in maximo 7.6)
For Maximo 7.6, change the workorder status to WAPPR from the backend or through MIF and then use MIF to delete the record(s)
I created an action that executes set FIRSAPPRSTATUS null and created an escalation with the condition of selecting a work order. After the escalation is completed, deletion will be available if the remaining conditions for deleting the work order are met.
I have a custom page with a form and a grid. When a row from a grid is deleted, I want to update some other rows. I am therefore handling the rowdeleted event. I confirmed (through debugging) that the event is firing correctly and that the data is being updated correctly.
The only issue I have is that the screen still shows the old values. My delete row correctly disappears but the other rows do not get updated.
For each row that I change, I am calling the Update method of the Data View. However, this still does not refresh the user interface.
Interesting, if I save, all my changes get correctly updated to the database. Which confirms that this is a UI isssue.
Is there any additional step that I need to perform to refresh the user interface? Or should I just avoid doing updates in Row Deleted event?
To guarantee constant optimal performance level, in the end of a roundtrip grids in Acumatica only update currently selected record. This behavior is by default. In case you insert/update/delete other records in the same grid within an event handler or an action delegate, it's always necessary to call View.RequestRefresh() to force the grid to update its entire content instead of only the selected record.
I managed to solve the issue by calling View.RequestRefresh(). However, I am not sure whether this is a standard practice. But I did find it used in several places in the Acumatica code
I'm trying to read in and loop through a configuration file which contains different mongoURIs and then trying to monitor their activity using mongo-oplog. I don't really know how to set the listeners (such as for update, insert, and delete) for all of these databases dynamically. Any ideas as to how I can go about doing so?
This is what I ended up doing (in case it helps someone out in the future).
I stored each URI in a list along with anther list that contains it's details like DB and collection name, and it turns out that you can loop through the list and set up each mongo-oplog one by one.
After you're done doing that the listeners are still active and whatever action you specified will be executed without you having to do anything related to the mongo-oplog again.
I'm trying to figure out how ExpressionEngine deletes entries.
I've written an log-like extension that tracks when an entry is created. When I delete an entry through EE's edit section, the entry is also removed from the separate table I created for my extension.
How does EE know to delete the row from my table when the entry is removed? One of the columns in my table is `entry_id`. It would seem like EE automatically checks all tables for a entry_id column and if the value matches the value being deleted, the row is removed. Can anyone confirm this?
It would explain why I didn't have to make a function that hooks into delete_entries_loop to achieve this functionality.
That's very odd. That behavior would be insane if it was indeed the case!
Looking at the delete_entry() method of the Channel Entries API, the deletions are very specifically limited to:
channel_titles
channel_data
category_posts
relationships
comments
comment_subscriptions
channel_entries_autosave
entry_versioning
The Channel Fields API is also called, to let fieldtypes delete what they need to from their own database tables based on the entry being deleted, but only if they contain a delete() method.
I'd suggest turning on the output profiler, then running the deletion routine to see what queries are being run.
I have an NSTableView which is populated via a CoreData-backed NSArrayController. Users are able to edit any field they choose within the NSTableView. When they select the rows that they have modified and press a button, the data is sent to a third-party webservice. Provided the webservice accepts the updated values, I want to commit those values to my persistent store. If, however, the webservice returns an error (or simply fails to return), I want the edited fields to revert to their original values.
To complicate matters, I have a number of other editable controls, backed by CoreData, which do not need to resort to this behaviour.
I believe the solution to this problem revolves around the creation of a secondary Managed Object context, which I would use only for values edited within that particular NSTableView. But I'm confused as to how the two MOC would interact with each other.
What's the best solution to this problem?
The easiest solution would be to implement Core Data's undo functionality. That way you make the changes to Core Data but if the server returns the error, you just rollback the changes. See the Core Data docs for details.