Troubleshooting data file issues requires that you have someone that knows SQL (editing field values, deleting orphaned records, etc.)

Yes that is true.  Thank you.   Is the availability of programmers easier in creating modifications with a sql database or is that irrelevant to having Providex vs SQL

What types of modifications do you need?  User-defined scripts are written using the BOI which is available in SQL or non-SQL versions.

We have a custom module written for our MAS200 (Sage 100) Providex software.  If we had the sql database, with either Sage 100 or Sage 500 would it be any easier to transfer the code to another programmer to maintain.  I am under the impression or myth that having SQL gives more flexibility in that way.  So I have to ask, why would a mid size company ever choose a sql version if it requires more hardware.  Is this for companies that would have an inhouse SQL programmer and database expert?

You are mistaken on a few points. Having the SQL back end helps your reports run a lot faster, that's about it. The ProvideX version processes faster, even benchmarks released by Sage some time ago confirmed it. As far as processing speed goes the SQL version is barely faster than the Standard version. The Advanced version (client/server) is the fastest as far as processing speed goes. You would not be able to transfer the code from Sage 100 to Sage 500 because all the tables and fields are completely different, well except for the name Sage in the title. Personally if you are looking at moving you should look at X3. Sage is pretty "hot and bothered" about X3 so I expect them to get the lion share of development efforts.  

Now if you say you have a custom mode written for you Sage 100 Advanced then you should probably stay there to get max ROI.  Plus a lot of flexibility is being added to Sage 100 as far as scripting ability goes. I would ride it out a few more years.

Hi BigLouie,

I hope you don't mind rehashing this discussion.  We are currently looking to upgrade from Sage 100C Advanced 2016 to the 2018 build and are experiencing the same quandary about going to Premium SQL.  I have read many articles speaking to the benefits of the SQL back end.  Although I don't fully understand how this would help us specifically, I do get SQL is easier to query.  Do you know how this works for backups.  Is it possible to do transactional rollbacks if needed?  I understand F9 (GL query) doesn't integrate with Premium.  Have you had experience with F9 vs. what's available in Premium?  My biggest concern is around the transaction processing speed.  Can you quantify this for us?  Are we talking milliseconds, seconds or minutes longer?  We have a handful of keyboard shortcut users, will they be disappointed moving to Premium?  We initially started looking at Premium to resolve some of our glitchy issues with printer servers and cloud performance/connectivity to the Sage server.  I'm not sure if Premium would be the answer for this, however, speed is definitely a deciding factor.

Also, any input on custom reports transferring from Advanced to Premium or same issue applies with new database and reports wouldn't work?

Any input you can give would be greatly appreciated.  Not many specifics are available on this topic and it would be great to speak with someone who's lived it.

Garrett, can you provide more details. How many users do you generally have logged in at any one time. Do you have any remote users. 

We have around 27 users active at any given time.  Everyone accesses the SAGE server via terminal servers.  Sage is currently setup in a cloud environment.

I highly recommend looking into going with Premium.  Not only do you have that ability to restore to a specific point in time (depending on transactional backup schedule) you also have the ability to write and schedule backend SQL queries to generate reports. 

As an example one of the reports that was manually being kicked off by my Accounting department would take anywhere from 30-120 minutes now takes 2-5 minutes with a SQL job that is on a nightly scheduled SQL job.

Existing custom reports can translate from Advanced to Premium (with a few obscure and rare tiny caveats / exceptions which have work-arounds).