Why does rec.MODIFY work like this?

headley27
headley27 Member Posts: 188
edited 2006-12-01 in NAV/Navision Classic Client
I wrote some quick code to update the allowed posting date range in the General Ledger Setup table.

Essentially, our NAS runs on a timer and shortly after 12:00AM on the 1st day of the month it would fire some code to set the 'General Ledger Setup Allow Posting From' field to the 1st day of the month and the 'General Ledger Setup Allow Posting To' field to the last day of the month. At least that is my wish.

Here is the quick sample:
   //Some Other Code Here
  
   //The code that performs the modification
   GL_Setup."Allow Posting From" := FDOM;
   GL_Setup."Allow Posting To" := LDOM;
   GL_Setup.MODIFY;
   COMMIT;

    //Some Other Code Here

I am really confused as to why all the other fields for this record were reset to their default values.

Do I have to all collect the original values and specify them in code?
I would hope not. There must be something simple that I have missed.

I also noticed that the Primary Key of the affected record is blank. I am not sure how big of a deal this is considering that there is only one record in the table.

Finally, I did not perform any GL_Setup.SETFILTER, GL_Setup.RESET, or GL_Setup.FIND('-') type code as there is only one record in the table.

Any insight would be greatly appreciated.

Thank you.

Answers

  • ara3n
    ara3n Member Posts: 9,258
    hello you need to go a GL_Setup.get first
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • Mbad
    Mbad Member Posts: 344
    Did you remember to do a GLSetup.get? And please please please do erase that commit.
  • headley27
    headley27 Member Posts: 188
    No, I did not since there is no primary key specified for this record.

    This is what the Navision Documentation states:
    GET (Record)
    Use this function to find a record based on values stored in primary key fields.


    Two more questions then:

    Will the blank primary key cause an issue when using GET?

    What problems are caused by the COMMIT statement?
    I thought that this simply makes the change immediate.
    The timer will make the change to the G/L Setup Table and will then start other reports. My thought is that the date range change would be committed and would not rollback in case one of the later reports failed.

    Thanks for your help.
  • ara3n
    ara3n Member Posts: 9,258
    that's what commit does.

    Even if the PK is blank doesn't mean that you don't need to do a get statement

    GLSetup.get is the same as GLSetup.get('');
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • headley27
    headley27 Member Posts: 188
    Wonderful. Thank you!!
  • headley27
    headley27 Member Posts: 188
    I would like to clarify one more thing.

    I would gather that rec.MODIFY works for me in other situations (pulls all fields) when I loop through a full or filtered recordset using FIND..REPEAT..UNTIL..NEXT... because I am still fetching the record (in lieu of GET).

    Since I can do this what is the advantage of GET? Is it so I can use less lines of code to jump to a single record? Is there a speed benefit? Something else?

    Thanks again.
  • Miklos_Hollender
    Miklos_Hollender Member Posts: 1,629
    I think there is a clear speed benefit on native. I'm not sure there is one in SQL but at least there is a benefit of writing only one line instead of one for each field in the key + the FINDFIRST.
  • SteveO
    SteveO Member Posts: 164
    Yup, the advantage of GET is less lines of code when compared to the average lines of code needed for a FIND('-') or FINDFIRST.

    They both perform the same in terms of performance.
    This isn't a signature, I type this at the bottom of every message
  • headley27
    headley27 Member Posts: 188
    Clears that right up. Thanks everyone.

Categories