Table 2000000039 is not available and cannot be opened

shepardassocshepardassoc Posts: 25Member
edited 2009-11-06 in NAV Three Tier
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.

Comments

  • shepardassocshepardassoc Posts: 25Member
    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.
  • cjeromecjerome Posts: 2Member
    Try setting the report properties - UseSystemPrinter to Yes. It worked for me.
    Regards,
    Jerome Cader
  • shepardassocshepardassoc Posts: 25Member
    Just wanted to say setting the report UseSystemPrinter Property did the trick. Thanks for your help.
  • rdebathrdebath Posts: 383Member
    That table is the "Printer" table.

    The only placed it's accessed from standard C/AL is the FindPrinter trigger in codeunit 1.
    Robert de Bath
    TVision Technology Ltd
  • shepardassocshepardassoc Posts: 25Member
    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_CintronDave_Cintron Posts: 187Member
    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?
    Dave Cintron
    Dynamics West
    http://www.dynamicswest.com
  • shepardassocshepardassoc Posts: 25Member
    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.
  • clayfoxclayfox Posts: 23Member
    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?
  • clayfoxclayfox Posts: 23Member
    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_CintronDave_Cintron Posts: 187Member
    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???
    Dave Cintron
    Dynamics West
    http://www.dynamicswest.com
  • Jens_M-PJens_M-P Posts: 39Member, Microsoft Employee
    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.
    Best regards,
    Jens Møller-Pedersen [MSFT]

    This posting is provided 'AS IS' with no warranties, and confers no rights.
  • Dave_CintronDave_Cintron Posts: 187Member
    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
    Dynamics West
    http://www.dynamicswest.com
  • Dave_CintronDave_Cintron Posts: 187Member
    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?
    Dave Cintron
    Dynamics West
    http://www.dynamicswest.com
Sign In or Register to comment.