How to see why you are getting CONSISTENCY Error

ara3n · **Posted:** Sun Dec 16, 2007 5:18 am

This is a trick I use whenever I do try to solve and see why you the db is getting CONSISTENT Error.

I create the following CU.

Code: Select all

OBJECT Codeunit 50000 Single Instance CU
{
  OBJECT-PROPERTIES
  {
    Date=10/11/07;
    Time=[ 2:50:02 PM];
    Modified=Yes;
    Version List=MOD01;
  }
  PROPERTIES
  {
    SingleInstance=Yes;
    OnRun=BEGIN
            IF NOT StoreToTemp THEN BEGIN
              StoreToTemp := TRUE;
            END ELSE
              FORM.RUNMODAL(0,TempGLEntry);
          END;

  }
  CODE
  {
    VAR
      TempGLEntry@1000000000 : TEMPORARY Record 17;
      StoreToTemp@1000000001 : Boolean;

    PROCEDURE InsertGL@1000000000(GLEntry@1000000000 : Record 17);
    BEGIN
      IF StoreToTemp THEN BEGIN
        TempGLEntry := GLEntry;
        IF NOT TempGLEntry.INSERT THEN BEGIN
           TempGLEntry.DELETEALL;
           TempGLEntry.INSERT;
       END;
      END;
    END;

    BEGIN
    END.
  }
}

And in CU 12 I add the following Code in function FinishCodeunit

Code: Select all

FinishCodeunit()
WITH GenJnlLine DO BEGIN
  IF GLEntryTmp.FIND('-') THEN BEGIN
    REPEAT
      GLEntry := GLEntryTmp;
      IF GLSetup."Additional Reporting Currency" = '' THEN BEGIN
        GLEntry."Additional-Currency Amount" := 0;
        GLEntry."Add.-Currency Debit Amount" := 0;
        GLEntry."Add.-Currency Credit Amount" := 0;
      END;
      GLEntry.INSERT;
      //MOD01 Start
      SingleCU.InsertGL(GLEntry);
      //MOD01 End
      IF NOT InsertFAAllocDim(GLEntry."Entry No.") THEN

Once you've made the changes. You run the SinleInstanceCU Once.
Then do what ever you do to get the consistency error.
Then Run the SingleInstanceCU again.
You'll see a list of GL lines Inconsistency. You will see why the transaction is not balanced.

kine · **Posted:** Sun Dec 16, 2007 11:18 pm

Good tip Ara3n =D>

kirankumar · **Posted:** Tue Dec 18, 2007 3:56 pm

This is really works ...

Can you please let me know the 'Kitting' Functionality Introduced in Nav-5.0.

I am really interested to know Such New things helps lot...

Regards
KiranKumar

Alex Chow · **Posted:** Tue Dec 18, 2007 11:54 pm

Very nice! Beats the alternative of turning off the CONSISTENT function and trying to figure out what happened.

Waldo · **Posted:** Fri Dec 21, 2007 1:15 pm

Nice nice

.
Tested and approved!

ara3n · **Posted:** Sat Dec 22, 2007 3:35 am

Alex Chow wrote:

Very nice! Beats the alternative of turning off the CONSISTENT function and trying to figure out what happened.

Yep, hopefully you are doing that in a backup db.

ara3n · **Posted:** Sat Dec 22, 2007 3:44 am

Waldo wrote:

Nice nice

.
Tested and approved!

I'm glad you are approving this one. :wink:

Alex Chow · **Posted:** Sat Dec 22, 2007 4:02 am

ara3n wrote:

Alex Chow wrote:

Very nice! Beats the alternative of turning off the CONSISTENT function and trying to figure out what happened.

Yep, hopefully you are doing that in a backup db.

Life would suck if I didn't...

Nonetheless, you still rock. :wink:

Waldo · **Posted:** Mon Dec 24, 2007 10:36 am

ara3n wrote:

Waldo wrote:

Nice nice

.
Tested and approved!

I'm glad you are approving this one. :wink:

Well, I've got to keep being objective :mrgreen:

Savatage · **Posted:** Wed Dec 26, 2007 7:27 pm

Question
I can impliment this but the users license gives them an error that they can't use this codeunit. (I had to give it a diff unused #) that is now out of our range.

would adding indirect permissons like
TableData G/L Entry=rimd help? or could it be inserted into another codeunit that is accessible (That would be sloppy tho I think)?

ara3n · **Posted:** Wed Dec 26, 2007 8:13 pm

No you don't need the permission for GLEntry.
The code only inserts into temporary table not actual table. As long as the user has indirect permission to post glentry, this would work.

As far as not in the license, this 50000 range, I'm assuming most customer start from that range to purchase CU.

Savatage · **Posted:** Wed Dec 26, 2007 9:04 pm

Now sure if the purchase structure has changed over the years but by puchasing 100 Reports didn't get us any more codeunits. Since it was new to us - we were more fixed on Reports, forms, tables, dataports. Puchasing a decnet number for codeunit spots 50000+ was not a big concern since we didn't even know what it was. And many of the things needed can be done using reports. So our seller never really mentioned to us that we could buy codeunit #'s (50000+) probably for our own good too :wink:

ara3n · **Posted:** Wed Dec 26, 2007 10:19 pm

I see.

I had the same issue with another customer as well.
It was taking too long to order the CU. So I used old CU that was used in 2.6 in 100 range but did not longer exists in 4.x but the client has still license to them.

For example Department and Project tables are no longer there but you can import a 2.6 fob object and then use them as other codes.

kriki · **Posted:** Wed Jan 02, 2008 9:26 am

Alex Chow wrote:

Very nice! Beats the alternative of turning off the CONSISTENT function and trying to figure out what happened.

With SQL, I have another trick:
I start the debugger with a breakpoint just before the error. Then I check the T17-table in another session (of course in a test DB!). The advantage of seeing uncommitted records...

davmac1 · **Posted:** Sun Jan 13, 2008 11:32 pm

I have a consistent problem and I believe I know exactly what is causing it. The sales tax calculation is a penny off versus the outstanding amount on one of the lines.
Does anyone know a fix for this?
The invoice rounding is set to .01

I think the problem is caused by the sales tax routine calculating the sales tax for the entire sales invoice, then adjusting the sales lines taxable amounts to make them balance, but not making a corresponding adjustment to the outstanding amount.

mibuso.com

How to see why you are getting CONSISTENCY Error

Who is online