.net Sdk Textfile And .xls Datasource Issues
Hello,
I am in the processing of finishing a label printing application in C# using the bartender .net SDK and have run into a major issue with getting the data to my bartender templates. I am listing the application constraints below to limit suggestions that may not work this project.
- The data passed to bartender templates needs to be in some type of human readable form (.txt, csv, .xls, etc.) so that an end user can go into a file and edit for adhock printing.
- The data needs to have headers detailing what each field is because there are 60+ fields in each datafile.
- The data fields can't be guareanteed to be in the same order or always present in every datafile
- The system is constantly in use by multiple users possibly printing the same template with different data
We initially used the default doublequoted comma text file format which worked beatifully. The problem with this approach is that the templates don't appear to actually reference the fieldnames for data binding. It seems that bartender uses the index number of the fields rather than the actual names and they names are only there to aid in creating templates. You can see this behavior if you move field 1 (invoice#) to field 2 (purchase order#) and change the header names to match. When you print a lable after the fields have been moved with the correct header names PO will show up where invoice should.
To get around this problem we started outputing all data in a .xls file. This hard binds the data to the names of each field and works perfectly. The problem with this approach is that there is no way programmatically change the .xls file used for data at print time. The data files are created on the fly from multiple databases and many users may be printing the same label (with different data) at the same time. Because of this it isn't possible to simply overwrite one file and hope that no else is going to try to read data from that file with another print request.
The only solution that I have found which may possibly work is to use a DSN as the label template database and then programmatically change the DSN connection string to the data file for each print job. I am afraid this approach is going to have lots of issues. The first one I see is that users wanting to do an adhock print will have to either log into the server and manually change the DSN to their datafile or they will have to completely change the database connection in the template. The other issue is how the DSN is going to behave being rapidly changed in the background. I fear there will be times when a label prints completely different data than what the user intends because of the disconnected nature of this approach between the actual datafiles and the templates datasource.
Is there anyway to accomplish what I am trying to do?
-
Hello All,
Would sending the data through an IDoc document bind the data by field names and solve all of my current issues stated above?
0 -
Which version of BarTender are you using? I've tried this very thing in BarTender 2016 recently for another customer and found that changing the ordering of the fields was fine so long as the field name in the text file header was also in use. In older versions of BarTender I believe this desired behaviour was not the case. Perhaps you could download a trial and test to see if it's fit for purpose: http://www.seagullscientific.com/downloads/label-software/barcode-label-printing-software-download/
0 -
Hi. We have the same problem with printing labels using .Net SDK version 10.1 SR1. Currently we generate SVC files on flow, open BTW file, get TextFile connection from it and set a path to the generated SVC file. If structure that is used on creating the BTW file is different than generated one - the mapping is wrong. BarCode controls shows data from other fields. If we print the the CSV file from BarTender (v. 10.1 SR4) it works correctly. It's difficult for us to migrate to other format because we have a lot of customers that already used CSV and have history. Could give any advice how we can solve it?
0 -
Alexey: I think your options are to either update BarTender to v10.1 SR4, or to modify the outputted CSV data so that columns are in the correct field index order. If I remember correctly, in SR4 we fixed a bug that allowed us to pick columns by name first, rather than by field index. Is there any problem with updating to SR4 as that is a free of charge update for v10.1 users?
0
請登入寫評論。
評論
4 條評論