Table 2000000039 is not available and cannot be opened

shepardassoc

I've upgraded a 6.0 database to 6.0 SP1 and I'm getting an error when trying to print from the RTC, "Table 2000000039 is not available and cannot be opened.". Most of the objects are still at 6.0 but I have imported the 2000000XX and 9900XXXX tables and codeunits to 6.0 SP1. I've updated the xp_ndo.dll on the SQL server to SP1 as well. I've compiled all the objects without error.

shepardassoc

I have isolated it to some codeunit. After importing all 6.0 SP1 codeunits it worked. Still trying to figure which codeunit is the cause.

cjerome

Try setting the report properties - UseSystemPrinter to Yes. It worked for me.

shepardassoc

Just wanted to say setting the report UseSystemPrinter Property did the trick. Thanks for your help.

rdebath

That table is the "Printer" table.

The only placed it's accessed from standard C/AL is the FindPrinter trigger in codeunit 1.

shepardassoc

Updating CU 1 to the 6.0 SP1 version was one of the first things I tried and it still erred out. Not sure what the relation is there. I did notice if I imported and compiled CU objects individually until all of them were at 6.0 SP1 it still erred out but if I imported and compiled all 6.0 SP1 CU objects as whole it worked. Very weird. There must be some dependency somewhere.

Dave_Cintron

I have tried setting the report property "UseSystemPrinter" to Yes and this worked, but is this really the solution - setting this properties of over 900 reports one at a time?

shepardassoc

Good question. I played around with importing CU's and I could only get it to work if I imported all 6.0 sp1 CU's in one fob file. I couldn't figure out or had the time to find the dependencies. An earlier post mention CU 1 accesses the printer table but I couldn't get it to work and on it's own. It compiled fine, just didn't seem to matter. It's definitely a weird error.

clayfox

I upgraded to SP1 and I am getting the same thing when printing or posting in RTC.

I did install the demo database on another server, with all tiers on there, and was able to print without this issue.

I have re-compiled all of my objects on two different servers but I think something is missing since I get the error. The table is not in the demo database either but obviously it is not looking for it I guess.

Should I export codeunit 1 from the demo DB and import it to my production DB?

clayfox

Found the issue in our code unit 1, when I replaced with default from demo it was fine. Vendor repaired it and problem went away.

Dave_Cintron

This is quite interesting. This did not work for me. What DID work is recompiling the reports, and there must be NO warning. For example, report 10143 OUT OF THE BOX gives a compile error on the RequestOptionsForm statement because the Page cannot handle this.

IF ISSERVICETIER THEN BEGIN
PageSetUpOptions;
EXIT;
END;
IF NOT MoreInfo THEN
UseSKU := FALSE;
RequestOptionsForm.UseSKU.ENABLED(MoreInfo);

Moving this into the IF ISSERVICETIER statement amazingly gives no compile time warning and no run time error.

IF ISSERVICETIER THEN BEGIN
PageSetUpOptions;
EXIT;
END ELSE
RequestOptionsForm.UseSKU.ENABLED(MoreInfo);
IF NOT MoreInfo THEN
UseSKU := FALSE;

So how many MORE of these hidden technicalities have been built into SP1???

Jens_M-P

The reason for the warning going away is that we do not generate C# code for blocks of code that will not be executed in the new stack - in this case the contents of the ELSE block (when you compile your object C# code is generated if the '3-tier option' is enabled - this C# code then gets compiled to IL when your object is invoked).
In cases where functionality has been disabled in 2009, it allows you to place your new A/L code inside the IF SERVICETIER block - and then leave the old implementation in the ELSE block - ensuring that the classic client works as before.

Dave_Cintron

Thank you Jens. Perhaps you can help with with some other issues. There seem to be a list of things that do not work if you do not start with the demo database but create a new database as we are used to doing.

- No charts and no import save for one at a time
- No style sheets for Pages and when you import the Form style sheets to Pages the RTC gives errors
- Print page gives a "no style sheet" error regardless of importing style sheets as above

Dave_Cintron

Jens, I have found that the steps in the Style Sheet tool 2.0 resolve those issues even if you are not using the 2.0 style sheets.

Another oddity I have noticed is that in saving a modified Report and NOT checking the compile box, if there is a duplicate DataSetFieldName you are forced to correct the error before saving. Is this not contrary the idea of saving a uncompiled version?