Rob Sushak has been a Dynamics SL developer on our team since 1996. He knows a few things about the programming toolset. Rob has an honors degree in Computer Science from the University of Illinois and has focused his career with us on extending Dynamics SL in various ways.
Rob has created custom reports using Microsoft’s SQL Server Reporting Services, assisted people in our Dynamics GP group with complex queries but mostly he has focused on adding new screens and even entire modules to clients systems that want more of their data not only tightly integrated with Dynamics SL-but an integral part of Dynamics SL.
Two of the larger projects Rob has worked on over the years have been with large, national, transportation firms that wanted their operations programs created in the same toolset as their Dynamics SL financial system. Another large project Rob worked on involved created a cash module for an investment bank on Wall Street with offices in Boston and Des Moines.
We are grateful to have Rob on our staff because he adds a level of depth that few Dynamics SL consulting firms have to support their consultants and clients.
Jack Boyer: Rob, you were involved when the product was called “Solomon IV” rather than Dynamics SL. What are the biggest and best improvements (in English) that you’ve seen to the toolset since VB 3 15 years ago all the way to VB.Net today?
Rob Sushak: The improvements that I find the most useful were adding color coding to the code window and adding the auto-completion feature. Those changes may not sound like tremendous improvements, but having the elements of the code color coded makes it much quicker and easier to read (and spot errors) and auto-completion helps speed up typing and getting command and variable names spelled correctly (spelling is not my forte, I’m a numbers guy, so this is helpful).
Jack Boyer: What about the stability of the programs you’ve written over the years-have they become more stable as the toolset has improved or were they always solid?
Rob Sushak: The programs have always been solid within their limits. The system has become much more capable over the years, which has allowed the programs to do much more than they have been able to in the past. What is desired will sometimes run into limitations in the toolset or database engine. That was much more frequent in the past, but it is still possible to get too ambitious.
Jack Boyer: I remember when you used to suffer each time you had a client that needed 2 or 3 grids on one screen where the grids had to communicate with each other. Has that part of the toolset improved? Is so, how long ago?
Rob Sushak: That is still an awkward situation, but there really isn’t much that the Microsoft Dynamics SL team can do about it. Functionality is not a problem if the screen you are creating is view only or if the grids are independent of each other, but when the screen is being used to enter information into dependent grids there is a problem keeping the tables in synch. Data that is about to be removed from a subordinate grid because of a change to the controlling grid needs to be saved or it will be lost, and the toolset is not set up to handle that situation. It is necessary to manage the database interface manually, tying to unusual events and saving all of the data changes made on the screen (not just the subordinate grids, since we want to avoid creating orphaned records). There really isn’t much that could be done to make this situation work within the Dynamics data model – there are too many possible permutations and it is contrary to the way the tools normally work. Trying to fix the toolset to handle this not common situation would result in more complicated solutions than just manually managing the interface.
Jack Boyer: Are there times you have had to go outside of the Dynamics SL toolset to get a program to do what you want? If so, please tell us the story.
Rob Sushak: I have written programs using a Data Tree control for customers who wanted to be able to navigate through data in that format. More frequently I have written programs to create Excel spreadsheets to match a model that they have provided. That involves figuring out how to manually make the changes in Excel to match the sample and translate that action into Excel VBA code (which will largely match the VB command I will actually need). Testing these programs tends to be fun – I make Excel visible during testing in case that will reveal problems (the final product doesn’t show Excel because it will run twice as fast), so I get to sit and watch the spreadsheet generate like a time lapse movie.
Jack Boyer: Share with us what you like about the Dynamics SL programming toolset compared to writing programs without the toolset or with other ERP programming toolsets that you’ve used.
Rob Sushak: The SL toolset automatically handles most of the database interface (or at least tries to). This helps simplify many aspects of coding for SL, but imposes restrictions on how things are done. Usually the gains are well worth it, but it does make accessing an outside data source more difficult. Writing apps without the toolset requires some additional steps. It also tends to result in screens that don’t quite feel the same as the other screens in the system. Of course, whether that is a good thing or a bad thing…
