When I was a little girl I loved to walk the dirt road up to my great-grandparents house and just visit - especially in the summer time. Living in the country with no other kids around, it was the most exciting place I could go. There were always beans to be broken, corn to be shucked, chickens to be fed, watermelon to be eaten, and stories to be told. I loved hearing them tell of times long gone and my curiosity kept them answering questions. And of course, being just a child, I believed everything they told me.
I remember one time in particular my “Big Mamma” and I were sitting on the back porch eating watermelon and spitting the seeds out to the chickens in the back yard. She had an old tree in the back yard, and on this particular day her little dog Susie was digging at the base of the tree. “What’s she digging for Big Mamma?” I asked. “Why, she’s digging for puppies. I’m sure she’ll dig them up soon!” she said.
Puppies? That was all I needed to hear! There were puppies to be dug up, and the sooner I could help dig them up, the sooner I could play with them! She gave me her old wooden ladle and I went to work. I dug until I had a hole deep enough to satisfy my curiosity, and realized I was now digging alone. Suzie had gone elsewhere.
It wasn’t until later in life I remembered that day and laughed at how she could tell me anything and my curiosity would take over. On a different summer day, she’d also occupied me with a salt shaker by telling me that if I sprinkled salt on a bird’s tail, I could catch it! I must have salted her entire front yard!
The poet Dorothy Parker once said “The cure for boredom is curiosity. There is no cure for curiosity.” I would have to agree with Dorothy. I recently got to one of those intersections of boredom and curiosity, and my curiosity has lingered! I started to look at NAV 2013 again. In particular, I was interested in how the actual C/AL Development might have changed. I found that the things that have changed seem to flow into categories, so I’m going to just outline a few of the ones I found for you into categories. (The remaining changes we’ll talk about at a later date. I’m not done “digging” those up yet.)
Dataports and Forms are no longer used in NAV. These have been replaced with XMLPorts and Pages.
XMLPorts now also use the properties AutoSave, AutoReplace, and AutoUpdate as once did Dataports. They have also inherited the triggers OnBeforeModifyRecord and OnAfterModifyRecord, which make the even more capable of replacing dataports. (I don’t know about you, but I was never fond of dataports anyway!)
The new object type of QUERY makes creating an extraction of data as gentle as a summer breeze! Now folks, this is something to get excited about! Check out this video by Greg Kaupp showing how to use the new QUERY object – and the new Chart Builder function. The ease of creating QUERY objects very well may replace some of the simpler reports that developers are often tasked to create.
UNLIMITED CODE AND TEXT FIELD LENGTH
You no longer have to determine the length required for CODE and TEXT data type fields in NAV. However, if you want to mandate a length maximum, you can do so. Otherwise, just leave the length blank.
I’d use caution when doing this, and consider the altercations that could occur with other fields within the database. Any NAV developer can tell you that an “overflow” error can occur when moving one field into another that’s too small to hold the full contents of the inbound data. This may seem like a blank check written for endless data, but understand that limits can be a good thing as well. Defined field lengths keep our data flowing nicely to space-limited fields in other tables, reports, and pages.
A few properties have been renamed to reflect the fact that forms are no longer an object type in NAV. They have been renamed to replace “form” with “page” in their names as follows:
A couple of handler functions also changed names. ModalFormHandler became ModalPageHandler, and FormHandler became PageHandler. (Handler functions were introduced in NAV 2009 SP1 for test units. To learn more, click here.)
We no longer use the IMPORT and EXPORT functions to load and download BLOB data, which is known in SQL as an IMAGE data type. We now use CREATEINSTREAM and CREATEOUTSTREAM functions. Likewise, the Import/Export property called SubType (Bitmap, Memo, User-Defined) is gone.
As always, the CALCFIELDS function must be used to pull the BLOB into memory. However, BLOB’s are handled a bit differently in NAV 2013 with OutStream and CALCFIELDS. In prior versions if you were writing a blob to an OutStream, but used CALCFIELDS prior to calling an INSERT or MODIFY, your CALCFIELDS would return what was in the stream. In NAV 2013, it will return what is in the database. And, if you call the CALCFIELDS function on a new record that has not been added to the database, you will clear the BLOB field in the record.
SIFT INDEX DECOUPLING
Flowfields, as we know, are not actual fields in SQL. These are calculations defined in the table based upon certain filters, and flowfield functions. In the past, to calculate a flowfield, which gives the field a value, you would have to associate the field to be calculated as a SumIndexField on a Key to the table in which the data resides. A SIFT Index would then be maintained to make calculation of the field easy and fast. However, as records in the table were modified or inserted, the SIFT index had to be maintained as well, which slowed performance.
In NAV 2013, the SIFT index has been decoupled from flowfield calculations. In the event that not all fields in the flowfield calculation exist in a key, or the key does not have the calculation field listed as a SumIndexField, it will still calculate the flowfield. However, it will read through "all records in the base table" to calculate the value. I'm assuming that the documentation that states "all records in the base table" meaning all that are within the given filter set, but that is a bit unclear. You can read more about the SIFT changes here. The same applies to the CALCSUM function that totals a field for a group of records.
In my humble opinion, this is a matter of “The Good, The Bad, and The Ugly”. It’s good that they’ve been decoupled, because that allows for faster performance for inserting records. It’s bad that it’s going to be a performance hit when we do calculate the value – provided the conditions for SIFT have not been met and it has to read "all records in the base table". It’s truly UGLY that the error will no longer be given to tell you that you must add a key or SumIndexField for the calculation, which would prevent those performance hits on calculations. Perhaps you can think of how this would be beneficial, but I’m a bit afraid the evil outweighs the good on this one.
But I am happy to report that we have a new function that will eliminate the need to calculate a flowfield for each read of the record. SETAUTOCALCFIELDS will allow you to define, ahead of a FIND/NEXT record loop, the fields you want to calculate. This betters performance in that the calculations are done all at once, rather than on each record read.
There are other changes in NAV 2013 related to C/AL Development that we will discuss later. But in the spirit of curiosity and summer filling the air here at the Kentucky office of ArcherPoint, I just want to share with you my favorite Dorothy Parker Poem, called “Inventory”.
"Four be the things I am wiser to know:
Idleness, sorrow, a friend, and a foe.
Four be the things I'd been better without:
Love, curiosity, freckles, and doubt.
Three be the things I shall never attain:
Envy, content, and sufficient champagne.
Three be the things I shall have till I die:
Laughter and hope and a sock in the eye.”
― Dorothy Parker, The Complete Poems of Dorothy Parker
But in return to Dorothy, might I add:
Dearest Dorothy, I have objected,
For as to life I have reflected,
Love, curiosity, freckles, and doubt,
I hope to never be without!
Other Microsoft Sites
I'm a Customer
I'm a Partner
Use the official Twitter tags:
#MSDYNCOMM | #CONV13