When I update a table through a data block, I am getting an error in the parent form "FRM-40654 Record has been updated by another user.Re-query to see change". I have looked into Oracle forums and tried the changes in properties. There are no triggers also. It Forms 6i. How can I trace where exactly the error is happening in the form? I tried to enable the database trace within the form load. But it is not creating trace file. I am opening a data block from the form on a button click. How can I refresh the form with latest data when I comeback from the datablock?
it's been awhile since I used Oracle forms but I believe you can deal with this by wrapping your update in a package. Then from the trigger that initiates the save create a Declare Begin Exception End block to catch the FRM-40654.
When this event is caught in the exception block try requerying then updating the information by calling the packaged procedure again.
Related
I am currently writing dwh loaders which get data from restapi then mainly inserts from database to database. There is log table with after insert trigger which call a "starter" function which starts the loading functon(s). So basically:
API -> check that last loading has FINNISHED succesfully -> insert to table -> insert to log table -> trigger (wait for FINNISH status) -> starter function -> loading function.
But i afriad that if something goes wrong with the procedure and it rolls back the full transaction (or at least there wont be finnished status)
Currently i use:
exception when others then
However im curios that is there any other error handling for trigger called procedure? Do you have any best practises?
Thank you in advance!
Never use WHEN OTHERS THEN. That will "swallow" errors you don't want to miss, like data corruption or other unexpected runtime events.
Normally, you shouldn't handle any exceptions in your trigger. Instead, write good code that does not cause an error under normal circumstances. You want that trigger to succeed, right? Under normal circumstances, you want the operation to fail if the trigger has a problem.
If you have to, catch and handle specific exceptions that are to be expected under ordinary circumstances.
I'm using MySQL Workbench and I am trying to create a routine. However, At the time of creating routine some error comes,then i deleted that routine. Now I synchronize the model with the existing database, the Routine group error is coming, though i remove that routine group. Can anyone help me how to remove this error from Model?
The _SYNTAX_ERROR suffix is added by MySQL Workbench to indicate that it found a syntax error in your routine code. Once you fixed that the name will change back to what you gave it. And then you can also synchronize your model.
I faced the same issue, cause i copy&pasted some c# code into a routine group, and it immediately became invisible by workbench. Synchronization now always reporte errors, even after deleting the whole routine group. The faulty code was stuck somewhere, inaccessible through the Workbench UI.
Just found a solution atm:
Do a regular synchronization and tell Workbench to change the sync-direction on the error entries. This will remove the faulty lines of code, even if they are not accessible through the Workbench UI.
Is it possible to create a warning message in a trigger in Firebird 2.5?
I know I can create an exception message which will stop the user from saving the record changes, but in this instance I don't mind if the user continues.
Could I call a procedure that generates the message?
There is no mechanism in Firebird to produce warnings in PSQL code, you can only raise exceptions, which in triggers will result in the effect of the executed statement that fired the trigger to be undone.
In short, this is not possible.
There are workarounds possible, but those would require 'external' protocols, like, for example, inserting the warning message into a global temporary table, requiring the calling code to explicitly select from that temporary table after execution.
SQL model does provide putting query on pause and then waiting for extra input from client to either unfreeze it or fail it. SQL is not user-interactive service and there is no confirmation dialogs. You have to rethink your application design.
One possible avenue, nominally staying withing 2-tier client-server framework, would be creating temporary tabless for all the data you want to save (for example transaction-scope GTTs), and then have TWO stored procedures. One SP would be sanity-checking and returning list of warnings, if any. Another SP then would dump the data from GTTs to main, persistent tables without doing those checks.
Your client app would select warnings from the check-SP first, if it returns any then show them to the user, then either call save-SP and commit, or rollback without calling save-SP.
This is abusing C/S idea, so there would be dragons. First of all, you would have to have several GTTs and two SPs for E-V-E-R-Y pausable data saving in your app. And that can be a lot.
Also, notice, that database data may change after you called check-SP and before you called save-SP. Becuse some OTHER application running elsewhere could be changing and committing data during that pause. Especially if you transaction was of READ COMMMITTED kind. But with SNAPSHOT tx too.
Better approach would be to drop C/S scheme and go to 3-tier model, AKA multi-tier, AKA "Application Server". That way your client app sends the "briefcase" of data to the app-server, it would be app-server (not SQL triggers) doing all the data validation, and then it would be saving it to data storage backend, SQL or any other.
There, of course, still would be that problem, that data could had been changed by other users, why you paused one user and waited him to read and decide. But you would have more flexibility in app-server on data reconcilation, than you would have with plain SQL.
Please see the image.
So here is a flow, wherein the first component executes a database query to find QAR_ID (single row), if it is found then all well. I am trying to put error handling into this. When no rows are found, it directs to tJava_11 which raises an java exception and that gets logged by another tJava component.
The problem I am facing is when it goes to error handling flow, it logs the error and just goes to the post-job section. However, I want Talend to take the OnSubJobOk route so that it continues with other steps instead of directly jumping to post-job section.
I know this is possible using subjobs but I don't want to keep creating 'n' number of subjobs.
Is there any way this can be done in the same job?
You could remove the runif and handle both scenarios in the get_QAR_ID into context component. ie query the database component's NB_LINE after variable, if it's <1 raise the error, else set the value. Your job would then flow to the onSubjobOk.
You can do something like this :
In tJava_1 you do your error logging if no row is returned by your query, and you continue to the next subjob. No need to throw an exception here only to catch it immediately after.
If any row is found, you continue to the next subjob (tJava_2) with an If trigger.
I have a CheckBox in my TabPage on my Form, if I select the checkBox, the value is saved in a Table field (present in my FormDataSource: ParametersTable).
I want to refresh the form when I enter in TabPage, just Like pressing F5.
Is it possible?
There is a great article about different methods of refreshing the form's data here. Here are the basic outline:
1. Refresh
This method basically refreshes the data displayed in the form controls with whatever is stored in the form cache for that particular datasource record. Calling refresh() method will NOT reread the record from the database. So if changes happened to the record in another process, these will not be shown after executing refresh().
2. Reread
Calling reread() will query the database and re-read the current record contents into the datasource form cache. This will not display the changes on the form until a redraw of the grid contents happens (for example, when you navigate away from the row or re-open the form).
You should not use it to refresh the form data if you have through code added or removed records.
3. Research
Calling research() will rerun the existing form query against the database, therefore updating the list with new/removed records as well as updating all existing rows. This will honor any existing filters and sorting on the form, that were set by the user.
4. ExecuteQuery
Calling executeQuery() will also rerun the query and update/add/delete the rows in the grid. ExecuteQuery should be used if you have modified the query in your code and need to refresh the form to display the data based on the updated query.
I strongly recommand that you read the article. Try to use some of the methods above or some combinations of them.
Start with research() method, it might solve your problem:
formDataSource.research();