In a recent post, I reported that when you have too many characters at the beginning of a package body (ours are the change history for an old package) PL/SQL Dev will not offer Describe or Test when you right-click on a module. If the package fails to compile, you see only the message "Compiled with errors" but no error list.
The magic number of characters is somewhere around 10,000. I can remove a single character and the problem goes away; add a character back anywhere in the initial remarks and the problem returns.
I my earlier post, I thought the problem could be solved by converting from "rem" to denote comments to "--", but further testing shows that is not true. In my first test the change must have lowered the number of characters in comments below the threshold.
Can this bug be fixed? Will it be?
It can be fixed and it will be. We'll add this for the upcoming 7.0.3 release.
I just realized that another ramification of the bug is this: The slash on the last line of my code is deleted.
Our standards require package bodies have a final line that is just a slash in order to compile correctly when the code is folded into our install scripts. In the past few months I have been dogged by that last line simply disappearing. The install script fails, the QA folks complain, I have to check out the code, add the slash, and check it back in. I was puzzled that it hadn't bothered me until recently and it only happens on some code. Only this morning, when it happened yet again, did I click and test for this error. Sure enough!
I sure hope the fix will address that part of the problem as well.
I just installed 7.0.3 "final beta". The problem isn't fixed at all.
No, but it will be
.
I just returned from vacation and was pleased to see that v7.0.3 is released. I have installed it, but I find only one of the 3 problems I reported above is fixed.
The problems arise when you have too many remarks at the beginning of package code; "too many" is somewhere around 10,000 characters. The problems are:
1. When the package fails to compile, you get a message "Compiled with errors." but not a hint of what the errors might be.
2. When you right-click a program unit in the browser, the menu does not offer Describe or Test.
3. When you save the package code, if your last line is a single backslash (/), the last line is deleted.
Only #3 is fixed by v7.0.3. The other two disappear only if you delete the remarks code.
I hope you misunderstood my descriptions and the other two problems are easily fixed.
The three problems seem so unrelated to me. Are there many others that I have yet to discover?
Problem 1 should be fixed. If this is still a problem, please send me a demo source.
I think I've stripped the problem down to bare bones in the code below. In the .pkg code, I've commented out the variable g_body_version so the .bdy compile will fail.
Problem 1:
When I compile the .bdy code I get the message "Compiled with errors" but no detail of the errors. If I delete one character...any one character you want...from the rem lines, I get the compile error list.
Problem 2:
If I remove the comments from g_body_version so the .bdy will compile, then I right click on the function, Test is not offered on the menu. When I remove any character from the rem lines and compile, then Test and Describe are offered on the menu.
The code:
CREATE OR REPLACE PACKAGE comp_err is
--
-- Global variables
g_package_name varchar2(20) := upper('comp_err');
p_st_spec varchar2(15) := '$Revision:41$';
g_spec_version varchar2(10) := ltrim(replace(substr(p_st_spec,
instr(p_st_spec, ':') + 1),
'$'));
p_st_body varchar2(15);
--g_body_version varchar2(10); -- set in show_version function
--
-- return the package spec and package body version information
function show_version return varchar2;
end comp_err;
/
REM comp_err.bdy
REM package body create for comp_err - description
REM
REM *********************** History LIFO ORDER ****************************
REM Date Who Comment
REM ---------- ------------ -----------------------------------------------
REM 08/06/02 Jeff Moritz
REM 08/06/02 Jeff Moritze v27, added procedure for closing cursors.
REM 08/06/02 Jeff Moritze v26, inserting distinct records into bl_bill_ap_temp
REM 08/05/02 Jeff Moritze v25, fixed the bl_bill_ap_temp query from invalid number error
REM 08/05/02 Jeff Moritze v24, added logic to keep error messages flowing
REM 07/24/02 Marilyn Fish v23, Code added to insert record into bl_bill_accounts_provider
REM for providers on an account that do not have charges for
REM the current billing.
REM 07/10/02 Marilyn Fish v22, Added previous_date_read and added bundle_tax_ind
REM to bl_bill_accounts_provider insert.
REM 07/03/02 Marilyn Fish v21, Columns final_bill_ind, estimate_ind, scan_line
REM added. Initialized penalty amounts to zero.
REM 06/24/02 Marilyn Fish v20, Added account_number to order by of account_c
REM 06/24/02 Marilyn Fish v19, Additonal changes to print_prep.
REM 06/24/02 Marilyn Fish v18, Dynamic sql v. of print_prep proc added.
REM 06/24/02 Marilyn Fish v17, Additional changes to error_log insert.
REM 06/19/02 Marilyn Fish v16, Inserts to bl_bill_print_error_log added.
REM Consumer_number parameter added to account_c
REM When abort_error exception raised, error_msg
REM inserted into bl_print_batch
REM 06/17/02 Marilyn Fish v15, Changed bl_providers to bl_provider_services
REM where provider_role is selected.
REM 06/06/02 Marilyn Fish v14, Added charge_code to bl_bill_charges and
REM added first_name, last_name to bl_bill_
REM consumer_statements
REM 06/03/02 Marilyn Fish v13, Modified parameters for process_penalties
REM 06/03/02 Marilyn Fish v12, Added code to assemble code_line value
REM 05/30/02 Marilyn Fish v11, fb/cr/tdsp_provider inserted into bl_bill_services
REM 05/14/02 Marilyn Fish v10, Functions without p_format passed in, altered
REM account_c
REM 05/14/02 Marilyn Fish v9, Changed domain ref to Bill Spec Proc Code
REM 05/14/02 Marilyn Fish v8, Added tariff_type to bl_bill_services.
REM 05/13/02 Marilyn Fish v6, Mod to correct problem with call from sql.
REM 05/11/02 Marilyn Fish v5, select change in calc_amounts
REM 05/11/02 Marilyn Fish v4, Overhaul of code.
REM 04/31/02 Marilyn Fish v3, Modified parameter in penalty_calc_amount.
REM 04/31/02 Marilyn Fish v2, penalty procs now call from bldelinq.bdy
REM 01/02/02 Marilyn Fish v1, initial version
create or replace package body comp_err
is
-- Package variables and exceptions
abort_error exception;
dup_key_ins exception;
pragma exception_init(dup_key_ins, -1);
--
-- Function and procedures
--
-- Return message with version information
function show_version return varchar2 is
--
-- Program Data
/* Variable to hold the software release string */
x_software_release varchar2(10);
/* Message to return with version information */
version_message varchar2(200);
/* Get the software release from the system table */
cursor get_ut_system_info is
select software_release from ut_system;
begin
-- begin show_version
for x in get_ut_system_info loop
x_software_release := rtrim(ltrim(x.software_release));
end loop;
version_message := g_package_name || ' Package: ' || x_software_release || '.' ||
g_spec_version || '.0 Body: ' || x_software_release || '.' ||
g_body_version || '.0';
return version_message;
end show_version;
begin
p_st_body := '$Revision:179$';
g_body_version := ltrim(replace(substr(p_st_body,
instr(p_st_body, ':') + 1),
'$'));
end comp_err;
/
The problem is actually related to this line:
REM package body create for comp_err - description
If you remove it, or change the wording so that "package body" no longer appears on this line, it works okay.
We'll fix this too.
I disagree. By removing that line all you did was remove a bunch of characters out of the remarks. If you remove that line but substitute the same number of characters for the stuff you removed, the problems still exist.
I'm still convinced that the error occurs when you exceed some magic number of characters in remarks preceding the actual code. Convince me otherwise.
I tested again, and it is indeed a little bit more complicated. Any object type name in the header will cause this error. In this case the following 2 lines:
REM package body create for comp_err - description
REM 08/06/02 Jeff Moritze v27, added procedure for closing cursors.
I'm not sure why I didn't run into this yesterday, and perhaps you can confirm this.
Like I said, we'll fix it. I will send you this fix as soon as it's implemented.
Are you sure you carefully replaced each character you removed from the remarks with another character? You may replace it with any character you want.
Please be sure you understand my premise: The code I sent has one more character in the pre-code remarks than the "magic number" that causes failure. If you want, I will write some code to count those characters and find the number.
Remove one or more characters from the remarks in the code I sent and both problems go away. Add the character back in and the problems reappear. It doesn't matter a bit which character(s) you remove. If you are simply removing the characters "package body" or "procedure" without replacing them, then you have removed "one or more characters". Unless you have replaced characters removed with an equal number of characters and found that the code I sent works, you have not tested my premise.
Now I have to apologize...sort of:
You are right in that if I substitute any character in the words "procedure" and "package" so they are not those special words, the body compiles with errors reported.
I am still right that if I leave those two words but delete any character from the REM lines, the body also compiles with errors reported.
I count 2938 characters in the REM lines.
I hope some developer looks at this and says "Ah Hah!" It sure looks like a very odd bug to me.
So I'm guessing this did not make it into 7.0.3?
I think I'm running into this or something very similar due to large comments in the package header.
The original problem was fixed in 7.0.3, but there was an unrecognized problem when the comment text before the package includes keywords. This will be addressed shortly.
Marco,
Sorry, what I should have said was that I'd noticed the initial problem before 7.0.3 but it seems to be working nicely now that I'm on 7.0.3. My apologies if someone thought I was saying they didn't fix the originally-reported bug.
Hopefully you can find and fix latest nuance quickly and release a patch for those suffering from it.
Best,
The problem referenced here used to be gone (in 7.0.3?), but now it seems like it's back in 7.1.
The problem is having a large number of (comment) characters at the beginning of a package body. When compiling that package, PLSQL Developer will instantly come back with "Compiled succesfully", but nothing will actually have been compiled.
If you get the number of characters just right (2828 characters in 59 lines, in my case), it will also truncate the package name shown in the tab of the program window.
Please look at (re-)fixing this problem. I was so happy when it was fixed before!
If you can send me the package by e-mail, we'll check it out.
Just getting antsy, my apologies.
Will this problem (leading comments preventing correct compilation of packages) be fixed in the next release? And if so, any idea on how far out this release will be (days/weeks/months)?
Hmm, can you resend me that package. I don't think we received it. Sorry for the delay...
You should have, since you replied to the email
. Your reply was sent on May 4th 2007 and had the subject "RE: remarks at the beginning of a package".
Regardless, I will send it again.
Did you receive it this time, or were you able to find the original email?
I just noticed an interesting wrinkle: I compiled a package body with an error, so the package body got a little red X in the browser. When I corrected the error and compiled the package body with excess remarks, I got the "Compiled Successfully" message but the red X didn't go away. Then I deleted the remarks and recompiled; this time the red X went away.
I just noticed a new wrinkle:
- I compiled a package body with an error so the icon got a little red X in the browser.
- I corrected the error and recompiled, but the code had "excess" comments at the beginning. Although I got the "compiled successfully" message, the red X did not go away.
- I deleted the comments and recompiled. This time the red X went away when I got the "compiled successfully" message.
Sorry! I didn't see "page 2" and thought my first message didn't make it!
I believe that's the same problem I was having. When it told you "Compiled Succesfully", it was lying. It didn't compile the package at all.
Unfortunately this can have some serious concequences, which is why I'm hoping this will get fixed (again) soon.
I think it actually compiles because it takes a while. Also, if I compile with all the remarks AND an error, it for sure compiles because it takes some time about it and it says "Compiled with errors." It won't tell you what the errors are, however.
Further experimentation shows that it fails to "uncheck" the body icon only when there is a keyword early in the comments. When I change the word "package" to "pachage" in the second line of my comments and compile a clean package body, the red check comes off.
Any idea yet on when this will be fixed?
I hope to have a fix next Monday. I will post a link in this topic.
I can be patient and wait for the next version (which you've already said should be "soon"), as long as the fix will be included in that version
You can download a fix
here .
Let me know how this works out.
A quick initial test with a few packages looks like the problem has been fixed. Thanks!
If I run into anything new, I'll definitely let you know.
Alright, here's something new (although maybe not related):
1. Open a blank package window.
2. Type two dashes followed by a few tabs (must be real tabs, not spaces).
3. Type some junk ("asdasdas...")
4. Using the mouse, click in the junk.
The cursor does not actually get placed where you clicked.
[quote]The cursor does not actually get placed where you clicked.[/quote]This does indeed seem to be an error in the patch version. We'll fix it.
And just in case this isn't the exact same error, something similar happens with:
xx[tab][tab][tab][tab]yyyyyy
clicking "on" the last tab puts the cursor somewhere among the "y"s.