Are there other methods (either supported or non-supported - but verified) of data import into Dynamics SL other than Transaction Import
*This post is locked for comments
Are there other methods (either supported or non-supported - but verified) of data import into Dynamics SL other than Transaction Import
*This post is locked for comments
We (eBridge Software) have a product that integrates various systems (EDI, CRM, WMS, Webstore and custom databases) into MS Dynamics SL. To accomplish this, we have developed numerous touch points (sales order, inventory, vendor info, GL transactions, etc) for integration into SL. What are you going to be creating in SL with the data you are importing from the external database?
Hi Brian,
I strongly advise again importing data directly into the SL tables - this will most likely lead to data integrity issues and stability problems in the future, cause a lot of errors for users, and make the system unsupportable. SL doesn't generally implement busines rules checking or data validation in the database layer - those occur within the application screen executable. Also, in most circumstances the relational integrity among tables is not enforced in the database either. It is tempting to bypass the application layer but it will probably result in a lot of pain.
Transaction Import and Object Model both layer on top of existing screens, making them almost equivalent to a user typing the information themselves. They inherit full validation, business rules checking, and customizations. To use them you will need some understanding of how the target SL screen works.
Transaction Import is not terribly difficult to set up - you generate a control macro for the screen you want to import into, then define a flat-text data file to match the control macro's format. It is run from within the SL environment and as such is best suited to periodic imports that are initiated by a user. I have also scheduled it from a command line for nightly imports. For Transaction Imports I usually create a Crystal Report that dumps the source data in the proper format to a text file. By joining the source table to the SL tables for the target screen you can also automatically filter out any records that have already been imported.
Object Model automates the user interface and requires programming skills. You would typically use it in a custom program to automate an existing SL screen. It has a steeper learning curve but allows more comprehensive automation of the SL environment than Transaction Import. It also provides a better mechanism to respond to errors than Transaction Import.
Either option will require some understanding of how the SL environment and applications work. If you need additional assistance I suggest starting with your Dynamics SL VAR - they can point you in the right direction and provide additional resources for your particular scenario.
Paul Phillips
I'm trying to import data from an external SQL database. I'd prefer to DTS, custom sp or something similar, without having to rely on VB or SOLOMON Object Model.
Thanks
Hi Brian,
What are you trying to import?
Jay
Hi,
You can use the Solomon Object model.
Regards,
Nagesh
Community Member
136
Mohamed Amine Mahmoudi
102
Super User 2025 Season 1
REUser
8