Maybe if you told us what data you plan on reading and writing to Sage 100 we could help determine the best way

I want to read & write from below data:

1. Customer list

2. Purchase Order

3. Quote details

4. Warehouse code

Request you to let me know the best possible way to write back to these data.

1. You can create new customers with code.

2. Yes you can create purchase orders with code

3. Yes you can create new quotes with code

4. Yes you can create new warehouses with code but probably easier to just do it manually.

You can read from all the tables involved with code or with ODBC.

VI imports would work too, for batch uploads.

BOI is powerful but has a high learning curve, while ODBC plus VI could be working in a matter of minutes.

Note that with ODBC you can only READ data, you cannot Write back to Sage 100 using the SOTAMAS90 DSN

Note that with ODBC you can only READ data, you cannot Write back to Sage 100 using the SOTAMAS90 DSN

If you truly understand how data is written to ProvideX files, a PVXPlus R/W driver might be the cheapest and fastest way to simple 100 updating. Keep in mind it might void your support with Sage if they discover it's use.

Sage let DSD use a custom version of ProvideX from MK for their now discontinued SQL Mirroring offering.

I think the R/W ODBC option should be a use at your own risk and Sage unsupported.

I would never recommend direct data edits, because that virtually guarantees corrupted data by ignoring all the Sage business logic and data integrity checks. 

Use the BOI, always.

I repeat this option is only for those that know what they're doing. Not for the casual user.

This isn't an issue if the PVXPlus R/W driver is stable or not, it's about blindly updating tables with no regard to 100 business logic. I personally would have no problems using this method over BOI if no UI interaction is required. (external scripting)

First line of the OP indicates this is someone new to Sage 100 (not someone who knows "what they're doing").  Master developers use the BOI, and so to the Sage programmers, for a reason.

I limit myself to direct data edits of UDF's, never Sage fields, because doing so is too risky (considering the lifetime of the system). 

Ex. someone later installs a new enhancement, or Sage adds new logic to the business object... Custom processes using BOI: no problem.  Direct data edits trying to manually duplicate what's done by the business objects: your logic becomes incomplete, leading to corrupted data.

Direct data edits for BAU processes (instead of using the BOI) is a terrible design strategy.

How do you feel about using ProvideX for file updates?

I have no idea what you mean by "file updates", but my use of Providex is extremely limited (to what is recommended by trusted sources).

The AR_CustomerCreditCard I created with a ProvideX CALL would be an example.

I get you're not an MD and programming blind isn't your methodology.

If your code is replacing BOI functionality, duplicating functions normally performed by Sage business objects (or installed enhancements), then that is not something I'd encourage. 

Trading short term gain for long term pain is not usually worth it.  We are not Master Developers, and we don't hesitate to recommend custom programming when it's needed by one of our clients. 

Just because something is technically possible, doesn't mean it's a good idea.

I don't see a big investment in source code modifications for rented software. What I have shared is maximizing functionality that is open and available. 

Just because you can hold a scalpel doesn't qualify you to do surgery.

The 'boogeyman' approach to limiting my abilities doesn't work for me.

You business practices are your own.  We do things our way because we consider the stability, supportability, and long term integrity of our client systems to be a top priority.