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.

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.

I'm not saying my methods are better, my point is one should be aware of all the options. I tend to work with clients that are searching for an affordable resolve.

I'm not saying my methods are better, my point is one should be aware of all the options. I tend to work with clients that are searching for an affordable resolve.

When the only solution to a customer request is risky, we explain the risks and let them make the call. Generally speaking, our warnings are taken seriously, and we avoid short-cuts / don't implement bad strategies (outside of temporary situations with mitigating practices to minimize risk).

Considering the complexity of ERP systems, and the fact they are pretty much mission-critical to our clients, risk avoidance recommendations are widely appreciated.

Telling a customer "I can do that" without explaining the bigger picture... is not equipping them with the information necessary to make an informed decision.

Mentioning R/W ODBC, to someone unfamiliar with the platform, without proper warnings... is irresponsible. 

(I'm done on this subject now).

All my posts included a disclaimer.

Thanks for your comments and feedback.