This solution has issues and issues with regard to the various Sage and Crystal versions, plus the OS compatability

I've stopped persuing the idea.

Thanks for the eyes

What I did is create a report using AR Customer Listing, then called that report from code and passed the customer ID as the parameter from the screen. The script then exports the report as a PDF and previews the PDF.

However, this is in 2019. Not sure if that same type of script would work in 2014. I recall being able to call a custom Crystal Report directly back in 2014, however the version of Crystal Reports changed somewhere along the way and you were no longer able to do that.

I find the LogiCity handles both these versions and is very reliable. It is $10/Year. You can script it or schedule it to print or email.

Yeah. that's why I.m not going that route. Each new version of Sage, Crystal Reports and OS .Net throws

too much upgrade overhead. If I had twenty reports and custom scripting to go with it...bad road.

I'm using an ODBC connection and a quick front end (possibly Access). Down side of that is the overhead

of Access and all it's baggage, upgrades, licensing $$...bah humbug

Lazarus is probably where I'll end up. Seems to just work with ODBC. At least ODBC isn't a moving target.

Awesome day though!!!

DataLinkViewer (Millet software) is a great ODBC based report running interface and very cost effective.

If you use Access with links to the SOTAMAS90 ODBC as your front end, the drivers are built into Windows so user's won't need to install but one version for maintenance. The ODBC is a moving target if you upgrade to Premium.

I will take a look. thanks Kevin

OpenOffice and Apache Office Base and Calc connects nicely to Sage and are free. A snag with those however is Sage won't recognize anything but Excel natively..and most companies don't snoop for alternatives to Office.

Just curious about the ODBC moving target. Does MS SQL not allow ODBC connections?

I'm guessing the table names and columns and types may be different in Advanced vs Premium.

If I wrote a quick Access 2003\2007\2013 etc using the ODBC 2/ODBC3 application 10 years ago, it would still work with Sage 100, unless I'm missing something. But it would certainly break if

an upgrade (or migration) to Premium.

Is that kind of the track you point to?.

SOTAMAS90 doesn't work for Premium, and SQL ODBC permissions are managed directly in SQL (not through Sage).  The big thing with this is you can't nicely change company codes on the fly with SQL, using direct queries.  The DLV software I mentioned allows quickly changing of data sources to run the same report against different companies.  Of course Sage custom reports can do that, but DLV is available to non-Sage users as well, since it is external.

SQL data also uses DateTime fields instead of dates, so report conversion won't auto-match Sage date fields... but that is a one time report conversion issue.

This Crystal thing bugs me. Clearly the builtin report dialog panels are passing data to the standard integrated Crystal reports. Maybe way back in 2014 nobody did this sort of thing. Who knows...but the

new solution will work better anyway.

...below are a couple ideas I use when coding to Sage and multiple companies.

Some things I do with odbc is I declare an array of ADODB.Connection objects (Pool) which I then create an array of odbc connections. So effectively I have (in my case) 5 odbc connection open at the same time, each to a different Sage company,  then I just set a generic ODBC connection handle to the ODBC connection to the company connection you want to work with, and pass the Sage company ODBC connection to whatever functions I'm working with.

So you can loop thru companies without closing one and opening another one.

I do the same for BOI connections

So i create 5 concurrent BOI sessions (one for each company), then pass the preinitialized pvxScript, and pvxSession objects specific to a Sage company to my boi code functions and save the inti/close overhead.

Always appreciate the insight guys