We have created an MSAccess labeling interface using an ODBC connection that uses Nicelabel for an ERP system. We currently have close to 100 customers.
In the current NL v6 compatible version of our interface, each PC (or User in TS environment) has a separate ODBC tied to their interface object that runs the appropriate label directly using a *.job object. Since the ODBC has a common name and the individual client interface calls out the *.job directly, the label knows which ODBC it is referencing and thus can print one label while another User/PC is printing a different label (or even same label format / different info).
We have now been told (and testing bears it out) that the *.job mechanism will not work with the standard print routine in 2017, but it will work in Automation. We tested & did get that to work, but that was on a single PC on which the ODBC was known and the service ran from that same PC. I have yet to test, but if we ran Automation from the server, which is what NL is recommending, we don't see how it will know which ODBC is the correct one to reference. Of course, for CS arrangements, setting up Automation at the Client PC will correct that, but for Customers that have TS arrangements, the only way we can see to do this is to have separate Automation routines for each User.
From what we read, sending a separate print file for each print request instead of using the ODBC would enable this to be centrally controlled, but that is a major developmental undertaking on our part.
Anybody have any other thoughts.
Issues related to label design (working with databases, data processing, RFID encoding etc.) and printing (from NiceLabel Express, NiceLabel Pro, NiceForm and NicePrint)
1 post • Page 1 of 1