Have you tried to interact with Crystal Reports via its COM/OLE automation API?

Fortunately I was able to get VB6 IDE with current Windows common controls to run on Windows 10 and MS Server 2016. Crystal reports is an integrated component with VB6 and a great tool to do what you are hoping for as a custom OCX.

No I haven't. I was hoping to find something easy, down and dirty so to speak. I'm not having much luck unfortunately.

Thanks for your help, Brenda

OLE with Office and Crystal offers a lot of possibilities but not a walk in the park to code.

I been using Excel's Power query. They are completely automatic and there's no VBA coding required, but I use a small macro to disconnect the data connections for external distribution. I did these sales and payroll projects a couple of years ago where the cover worksheet ("CombChart") has miniature versions of the larger charts on their own worksheet.

I been using Excel's Power query. They are completely automatic and there's no VBA coding required, but I use a small macro to disconnect the data connections for external distribution. I did these sales and payroll projects a couple of years ago where the cover worksheet ("CombChart") has miniature versions of the larger charts on their own worksheet.

Wow!

Nice job.

Yea well you're Connex! 

Dan,

Is Power Query ADO based? Do you bring in raw data and use Excel VBA for your presentations? Do you run into limitations (syntax) using the ProvideX ODBC driver?

If someone were doing extensive analytics / BI, mirroring to a SQL server would make sense. (or use Premium)

There are ADO functions available, but I didn't use them (nor would I know how). No VBA is required. No macros need be assigned to the charts. Just "Refresh ALL". 

A cool think about Power Query is that it accepts Crystal Reports SQL statements (sans the double quotes). So, if your comfortable with Crystal, you can get a jump start on creating a Power Query result set on which to base your charts. Just use a "Blank Query" and replace "SELECT..." with your query in:

= Odbc.Query("dsn=SOTAMAS90", "SELECT...")

I bet Sage 100 Premium could be more efficient if some of the logic in business objects were stored procedures / functions.

Sage's argument might be code exposure.

Definitely issues with the ProvideX ODBC like only one Left Outer Join. Although, the C/S ODBC can help a lot in an advanced environment. One can push criteria to the server (convert those date constants to Providex) and reduce network traffic and speed performance.

Perfect world as I see it would be install Premium on each workstation (installing only modules required) and point to a common SQL server.

WindX client / server needs to retire.