Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics SL (Archived) / Risks of moving custom...
Microsoft Dynamics SL (Archived)

Risks of moving custom process to C# non-SL app

(0) ShareShare
ReportReport
Posted on by mtiepruitt 95

Our client has a custom process developed via the SL SDK that imports sales orders from an external app. They want options for moving this process to a web service or standalone C# (non-SL) app. They are on SL 2011 FP1.

From what I’ve read, I understand that direct database access can be a risky proposition, since data integrity and business rules have to be manually enforced. So, here is my question:

If the only thing this custom process does is make database updates via Sql and SInsert1 calls, and we can extrapolate from the code exactly what the SQL statements are, would it be safe to replicate that functionality outside of SL (in a C# .NET environment)? It seems to me that the risks of data integrity/business rules violations would be minimal or perhaps even non-existent in this particular situation.

Am I missing something or over-simplifying in how I’m looking at this? Does my reasoning hold water for you experienced SL developers?

Thanks in advance,

Elton

*This post is locked for comments

  • Verified answer
    Community Member Profile Picture
    Community Member on at
    RE: Risks of moving custom process to C# non-SL app

    Hi

    To answer your question, SInsert function will Insert one record into each specified table within an existing database view

    Please find below the more information towards SInsert statements:

    SInsert1 is designed for SQL statements referencing a single table. In this case the TablesInsertingInto is always the name of the single table actually referenced.

    This function will insert one new record into each table referenced in the TablesInsertingInto argument using data from corresponding table structure arguments.

    For more advanced SQL statements having one or more table joins either SInsert4 or SInsert8 can be used.

    The referencing of more than one table does not automatically force the insertion of a record into every table in the view any time SInsert4 or SInsert8 is used on the corresponding cursor.

    A single record will only be inserted into each table explicitly specified in the TablesInsertingInto argument so long as each table name so specified is also referenced in the SQL statement which was used to initialize the current view.

    Thus, for example, if TableA and TableB are the only two tables referenced in the SQL statement used to initialize the current view then a value of TableXYZ would be invalid for the TablesInsertingInto argument.

    Note:

    The SInsert1 function uses the following arguments (SInsert4 and SInsert8 respectively have four and eight table structures and corresponding lengths. PNULL should be passed for unused table structure parameters as well as a corresponding length of zero such as PNULL, 0).

    Hope you got clarified

    Thanks & Regards

  • mtiepruitt Profile Picture
    mtiepruitt 95 on at
    RE: Risks of moving custom process to C# non-SL app

    Thanks for responding. I'm not sure if I explained my question adequately, so I will try to clarify.

    One part of this custom process creates a cursor for SOHeader, sets some properties on it, then calls SInsert1(CSR_SOHeader, "SOHeader", bSOHeader). What I'm trying to understand is if that SInsert1 call might trigger something behind-the-scenes within SL that I am not aware of, that would not be triggered by simply directly executing that SQL command? For example, if inserting a new record into SOHeader causes new records to be inserted in other tables -- not by a SQL trigger but by something internal to SL?

    Does that make sense?

  • Suggested answer
    Ram Peru Profile Picture
    Ram Peru 2,830 on at
    RE: Risks of moving custom process to C# non-SL app

    Hello Elton,

    One of my clients is using the slate web service to import the sales order into Dynamics SL. Here we need to pass the sales order information to Slate Web Service and it will create the records into Slate DB.

    Slate Control is the other application will use the records from Slate DB and create the orders using Solomon Object Model.  There is no data integrity/Business rule violation as we are using SOM (Solomon Object Model).

    We can use SQL option also for importing the data into Dynamics SL. But we need consider all the scenarios while writing the SQL injection. We need to mainly consider the tables (SOHeader, SOLine and SOSched)

    If we used the SQL option to insert the Sales Order data into Dynamics SL, There is the possibility of data integrity problem.

    Hope this explains.

    Thanks,

    Perumalsamy R

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Daivat Vartak – Community Spotlight

We are honored to recognize Daivat Vartak as our March 2025 Community…

Announcing Our 2025 Season 1 Super Users!

A new season of Super Users has arrived, and we are so grateful for the daily…

Kudos to the February Top 10 Community Stars!

Thanks for all your good work in the Community!

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 292,516 Super User 2025 Season 1

#2
Martin Dráb Profile Picture

Martin Dráb 231,432 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Featured topics

Product updates

Dynamics 365 release plans