Multiple DB Tables without Join 关注

0
Avatar
John Cummens

The below applies to Bartender Designer 2016 R6 - Enterprise Automation.

I have a shipping label layout that requires quite a bit of custom data be sourced from external data sources or otherwise manually entered. 

I need to be able to pull a row of data from a table corresponding to a product SKU.  This information will be used to populate fields such as color/size/upc/etc on the shipping label, corresponding to the product in the carton.

ALSO on the same label I need to pull a row of data corresponding to a store number; e.g. Address, city, state, zip.

These two data sources have zero common columns and cannot be 'joined' through the DB wizard.  Is there some way to actually add multiple, independent, database-links?

Previously I had done this all in Excel, using a single 'data entry sheet' that pulled up values from other sheets, and presented the compiled user-entered and excel-looked-up data to Bartender, so that it only had a single row containing all of the data for the label.  As we have undergone some staffing changes, I have been tasked with 'removing Excel from daily workflow', and as such, need to find a way to replace the excel-based multi-table lookup with something built-into the label that can be used from Print Station (e.g. from within query prompts).

 

Any information would be appreciated;

2 评论

0
Avatar
Peter Thane
评论操作 固定链接

Hi John,

I have not tried this in 2016 but in older versions of BarTender I have been able to fool the OBDC linking into thinking a join existed when one didn't by adding a column in each table and including the same data in each record on both tables (normally the number 1)  and then created the join based on these two fields,

I could then add on my query prompts for each table as appropriate.

Pete

0
Avatar
John Cummens
评论操作 固定链接

Thanks Peter;

I'll play around with that concept and see if I can get it working for these templates and tables.  Thankfully not many of the setups we use need multi-sourced data, so there shouldn't be too many tables to convert.

Much appreciated;

 

John

请先登录再写评论。