Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Here is my Load script that I'm trying to get to work, but it gets to about a minute and a half and stalls for a minute and then says "operation aborted". I'm assuming it's crashing as it's trying to make more synthetic keys.
I can't read through all of the script right now, but you say "I'm assuming it's crashing as it's trying to make more synthetic keys." If so, your solution is to get rid of synthetic keys. You should not have those. You do that by renaming fields so that there is not more than one field that links two tables together. If you need more than one field to be the link you should create a composit key. You can read more here: https://help.qlik.com/en-US/sense/Subsystems/Hub/Content/Sense_Hub/Scripting/synthetic-keys.htm
thanks, synthetic keys have been working great overall for me until now with more data across more tables.
Each of our tables needs to have two fields (contract and part_no) other wise the data has not been matching up like i need it to. then to match another table which doesn't have conventional dates, I needed to create a field that extracts the year out of the dates and the same for month. then I had QLIK automatically creating keys that matched part and contract together along with the date extracts. This is working fine for now with what I'm trying to accomplish, but the problem is that I need to change some of the fields to a different one and then it freaks out and aborts. here is my current model.
Synthetic keys rarely work great. Always avoid them unless you really know what you're doing and explicitly want them for some reason (but I can't really see what that reason would be, other than trying to save time when importing data). Read more on this here: https://community.qlik.com/t5/Design/Synthetic-Keys/ba-p/1472634
I believe you should resolve those synthetic keys by generating new key fields, for example hash128(CONTRACT, PART_NO, STAT_YEAR_NO, STAT_PERIOD_NO) as %contractPartStatKey in the tables PO_Lines, inv_value_per_period, inv_transactions_history_invoice_statistics, and remove (or rename) those original fields so that you have only one field that links them together. That's what's called a composite key.
Thanks for your help, I will play around with this later today.
right now with those fields all as part_no the model is working pretty good, whether synthetic keys are the right approach or not. I was able to make a concatenated field of year and period for all those tables so that eliminated a field which is good.
but my problem now is that I want to change the part_no fields in PO-Lines, Inv_transaction_history, and usage_by_part tables to say component_part instead of part _no. But when I edit the script to load part_no as component_part in those tables the load script just crashes every time.
basically how I’d like the flow to go is you have the invoices table connecting to the WVCO inventory table by contract and part _no. Then the component_part field would connect to the usage by part, PO, and transaction history tables, and those three are also connected along with the invoices by a common date field. These also need to be connected by a contract and component _part combo
i know that’s messy and most likely will be doing this on the SQL db side, but it’s just annoying to me at the moment that QLIK can’t seem to inherently handle what I’m trying to do.
I'm not sure, but it's probably because you have a field named component_part in the wwco_inventory table, and it could be that the new synthetic key that is generated when rnaming PART_NO to component_part makes Qlik crash for some reason. The solution is probably to avoid synthetic keys.
OK so I was looking in to the composite key and was able to mostly get them to run the script, eliminating most of them. but that's not ideal either.
The problem is that I can't filter on either contract or part as an individual field which I need to be able to do. is there a way that I can create composite keys and still filter them as separate fields? Because a composite key does not let me do that.
thanks for your help!
Yes of course! Keep the fields contract, part etc in one of the tables (the table where most of those values reside, if there are differences between tables). The problem with synthetic keys occur when there are multiple fields linking tables, but now that you have a composite key to link the tables you can keep the original fields in one of the tables and use those fields just as you're used to.
thanks again. Where I am at is that I can get rid of the synthetic keys for the most part, only to run in to circular references, and then trying to fix those means my data is not working out in visuals.
Here is the essence of my issue and hoping you can give advice! Tables and fields that I am trying to link up are:
TABLE: Invoices
fields: Contract, part_no, YEARMONTH
TABLE: Inventory Parts
fields: Contract, part_no
TABLE: WVCO Inventory
fields: contract, part_no, component_part
TABLE: POs
fields: contract, part_no AS component_part, YEARMONTH
TABLE: Inventory_transactions
fields: contract, part_no AS component_part, YEARMONTH
TABLE: Inventory_value_per_period
fields: contract, part_no AS component_part, YEARMONTH
this is what makes QLIK freak out and do abort the load, and I'm trying to get rid of the synthetic keys and then I'm getting circular references and it's all very frustrating
Thanks again!
I'm not fully following what happens based on this example, but I do want to mention the possibility that you may need multiple compound keys, if different tables share different fields. One compund key might be contract & partno to link some tables, while another compund key may need to be contract & partno & yearmonth to link other tables.
I recommend that you load the first two tables (just add EXIT SCRIPT; in the script where the second table has been loaded) and check your data model. Resolve synthetic keys and circular references that may have occurred. Then you move on and load three tables and check again, after that you load four tables and so on.