I am a novice user of Oracle Report Builder, so forgive me if the answer should be obvious.
I am attempting to run a 9i report, and I keep getting an error that appears like there is an issue with frames overlapping. I have two versions and both are getting the same error. One version is the report I want. The other is a stripped down version with only a couple fields, to narrow down what might be causing it.
Terminated with error: <br>REP-271187990: Virtual Memory System error. REP-0200: Cannot allocate enough memory. cavaa 22 REP-0002: Unable to retrieve a string from the Report Builder message file. REP-271187990:
Occasionally, it kicks out the message below when I try to run it, with no other accompanying details. The select runs and returns the desired results, and the function returns the ref cursor results as expected. The package is valid and compiled, so the query itself should be fine. There is only one query in the report, and I have tried various things, including stripping the report to narrow down the source of the error, with no luck. Any ideas to try would be appreciated.
Terminated with error: <br>REP-1401: 'qr_1refcurds1': Fatal PL/SQL error occurred.
It turns out that the problem was with data returned from my refcursor.
In the package spec I had one of the fields wrong field in the table.field%type declaration.
For those experiencing a similar error I would suggest:
If you have your SQL in functions, as opposed to right in the report, check your package spec to ensure your field order matches usage in the body.
If you have any overlapping frames in your report, this message can also come up. Check the object navigator for any hidden frames. They can be totally invisible, and the only way to know for sure is by checking in the navigator. Hint - Give meaningful names to your fields and text labels, so you can see what's contained in each frame. Also check the source of container frames is... but that's another REP error to enjoy.
Depending on setup, the first time you load a report it may error out referring to one of your queries. That happens after compile. Just try again, and every time going forward it's fine.
Consider the server patches mentioned above if your SQL statements are dynamic.
Feel free to add to this list if you know of others.
According to Oracle Support Note 430044.1 -
MS Windows: Reports 10g with Ref Cursors Fails with REP-200 and REP-65
Virtual Memory System Error [ID 430044.1]
This is a known Oracle Reports bug for MS Windows Platform.
Bug 5584001 DYNAMIC REF CURSORS DON'T WORK IN VERSION 10.1.2.0.2
REPORTS BUILDER
There are step by step instructions in the Oracle Note to apply the patch to resolve this issue. Also note, this problem is specific to MS Windows.
The suggested Oracle One-off patches are-
One-off patch 4505133
One-off patch 5634746
Log-on to Oracle Support, download the two patches and follow the step by step instructions mentioned in Note 430044.1 to apply the patch.
Related
Grakn is awesome, but it also seems very unstable.
The exactly same initial import queries -run in another keyspace- (meaning both were empty before) are only working in one keyframe, the other throws this stupid error:
Error status: 400, error info: facebookCategory doesn't have an 'isa', a 'sub' or an 'id'
In my scheme facebookCategory is defined like this facebookCategory sub category. Category is defined as category is-abstract sub entity.
So - what's wrong with Grakn?
This is a known issue we are working on right now:
when you start migrating data on a keyspace and for some reason your schema or data are wrong/missing, the keyspace sometimes gets corrupted. So when you will try to reload data - even if now everything is correct - you will get that error, again because the keyspace is corrupted.
We are working on this issue internally to solve it as soon as possible.
The error you get is trying to tell you that there is a corrupted schema, we will try to improve it and make it more explicit so that you don't think it's stupid.
We know Grakn is still far from perfect but we can assure you we are just trying to fix as many bugs as possible.
Please try to migrate everything in a clean keyspace, you can find also more issues discussed in our github repo and our support forum
I've seen this via the UI and directly through the REST API (which the UI of course uses) but the version search on a path does not return more than 10 results.
You can see this easily in the UI if you right click on a path with more than 10 versions and you choose Delete Versions. You see an error stating:
"Search exceeded the limit and some versions are not shown. Try running this action from deeper node"
This seems like a bug. I see no way to retrieve paginated results. Also, I'm going to try uncommenting this line in the main properties file:
artifactory.search.userQueryLimit=1000
But that seems ridiculous, what kind of default is 10?
The error you are getting seems to be related to the parameter that you added:
artifactory.search.userQueryLimit=1000
But one thing that you need to understand, the limit you got is that the search went over 1000 entries, not results. For that reason, the directory search worked. This search doesn't work with pagination.
If you wish to use a more efficient way to search for your binaries you might want to consider using Artifactory AQL as you can see below:
https://www.jfrog.com/confluence/display/RTF/Artifactory+Query+Language
According to https://randomascii.wordpress.com/2013/11/04/exporting-arbitrary-data-from-xperf-etl-files/, wpaexporter.exe should be the right tool to do so.
I manage to prepare a profile with the right data, but, unfortunately, wpaexporter keep trying to translate addresses, even if "-symbols" is not given to the command line, generating some useless
/<ModuleName.dll>!<Symbols disabled>
warnings.
This is annoying because part of our application use some Delphi code that can not generate symbols in a Microsoft compatible format. With addresses, we would be able to find the Delphi symbols in the call stack using map files.
Is there a way to extract call stack addresses from a wpr trace ?
Thanks, i completely missed processing options of xperf...
In the meantime, i found that LogParser (https://www.microsoft.com/en-us/download/details.aspx?id=24659) can also export an etl file to a csv (with actual values as well) :
LogParser.exe" "Select * from file.etl" -i:ETW -o:CSV -oTsFormat "HH:mm:ss.ln" > output_file.csv
From what i have seen so far, LogParser output might be more suitable for automatic parsing (only one line per event in the file, no header) while xperf output is more suitable for human processing (tabular representation).
Yes. You can also use xperf.exe. Have you tried the actions option?
xperf -a stack should help here I expect.
You can see detailed info with xperf -help processing command.
(This is a follow-up to an answer from an earlier question here.)
I have an Access 2010 database file containing a table with a Before Change Data Macro:
I can open the table in Datasheet View and add rows, and the Data Macro behaves as expected. However, if I open the table in Design View, open the Data Macro for editing, do something trivial like click the [+] beside one of the macro steps to expand the details, and then try to save the "changes" I get the error
The 'LookUpRecord' macro action has an invalid value for the 'Look Up A Record In' argument.
I have also tried to create the macro from scratch in a fresh Access 2010 .accdb and get the same error. I have tested this on three different machines: two machines running 64-bit Access 2010 and one machine running 32-bit Access 2010. All machines are fully patched via Microsoft Update. (That is, they are currently running version 14.0.7106.5003.)
While testing I noted that this appears to be related to an event-driven Data Macro trying to use LookUpRecord to perform a SELECT on the same table to which the Data Macro applies. Performing a SELECT on some other table does not seem to trigger the error.
My questions are:
Can anyone recreate this issue with a patched version of Access 2010?
Can anyone test this with an unpatched version of Access 2010 (e.g., fresh install from an early release) to see if a subsequent patch broke changed something?
Has anyone seen any documentation or Internet chatter to suggest that an event-driven Data Macro for a particular table should (or should not) be able to do a LookUpRecord by performing a SELECT on itself?
Edit -- 2013-12-19 14:10 UTC:
I just tested this with Access 2010 SP1 (14.0.6023.1000) and got the same results.
I think the issue is the table alias. If you open the table out in layout mode (just open the table NOT in design mode). You then get this:
You can now edit the macro freely (such as expand an action) and then save the macro.
I suspect this is an un-intended bug since if the table is opened in design mode then the table is locked and the macro cannot get/check verify the SQL used in the lookup command.
Note that if you JUST PLACE the table name in the macro designer then you have NO problem and this is what 99% of people do in this case.
Most most don't know you can free hand type in SQL here!!!
Upon save the designer attempts to verify the SQL against the table – but the table is locked in design mode. So in a round about way, this is a bug, but few encounter it due to few typing in SQL into that lookup record command.
I would as noted just open up the table by clicking on it and not use design mode to make changes. And note in the above screen shot how the event buttons are separate buttons and easier to hit then when opening table in design mode.
Note that in order to edit the Data Macros directly from Datasheet view the database must have the "Enable design changes for tables in Datasheet view" option enabled:
If that option is not set then the Data Macro buttons are disabled in Datasheet view.
Just wondering if any one might now how to fix this issue.
Every part of the databroker is created and also all the database connectivity is functional.
But once we try to place them together we come up with a error saying cannot create Null Databroker.
The thing that is really strange is that we have databrokers that are basicly the exact same working.
Can any one shine some light on this issue?
We worked on this together today. We did three things to troubleshoot and fix the problem:
we changed the calling workflow so that the dataset is refreshed inside the show-screen tags (previously, this was done before the screen was called).
we refreshed the dataset (a H2 db) and connected the database (before, it showed as pool not open)
we changed the database name to main
It is working now.
"Null databroker" suggests that the broker was not created correctly, although it doesn't look like that was the case since you don't mention having to modify it to get it to work.
In these cases it can be useful to look at the error logs through the admin app to see if there are errors being thrown at some time other than compile time.