i have a gen2 storage account with a blob container with multiple parquet files.
when i do a sync with odx it’s succesfull, the transfer gives me for 4 files the message “ is used by another table”. all other files in the same map go ok.
have tried to recreate the blob container, and recreate the parquet files again, same results.
Exact message:
The table folder 'parquet_taak_status' is used by another table with the id 9a510177-a130-4bcc-aaaa-5abefd42c1b9
how to solve / find the other table that is referenced to?
Please go to the Azure portal, and try to delete the table level folder in the data lake for the tables that are giving the error. Then synchronize and transfer again.
Please go to the Azure portal, and try to delete the table level folder in the data lake for the tables that are giving the error. Then synchronize and transfer again.
this can be pretty annoying indeed. It should be possible to do something similar to “Take ownership” in Deliver endpoints to resynch the extended properties for blob folders and files.
In some cases deleting the parquet files and starting all transfers again does not fix the issue though.
For some reason several of my ODX transfers stopped working last night.
After "Synchronize objects" all table mappings were gone.
The transfer tasks in the ODX were still successful and the parquet files in the ADLS Gen2 data lake were still there. But there were warnings like "The table folder 'rest_score' is used by another table with the id 60613c61-9788-4d0c-bb8d-4cd831858d03". I deleted all data lake folders an transferred all data again. That fixed the transfer tasks but the DSA mappings still failed.
It was a terrible pain in the *ss to fix all broken mappings (from ODX to DSA). Luckily I had an older TimeXtender project open on a different server so I was able to manually check all table mappings/field mappings.
Am I missing something? Why was TimeXtender (Classic, version 20.10.66) unable to fix these mappings? This was quite an expensive issue that took quite some time to repair.
@RLB what was the error message for the failing ODX transfers, do you know what caused them to fail? can you please explain what you mean by “The transfer tasks in the ODX were still successful”, when did they start succeeding again after failure, did you make any changes?
I mean that the transfer tasks themselves did not fail, but they succeeded with warnings. The warnings being the “in used by another table” message.
They started succeeding again after I had removed all file folders in the data lake like I mentioned above.
But the issue in the DSA was not fixed until I remapped all tables, because these errors did not go away:
Hi,
i have a gen2 storage account with a blob container with multiple parquet files.
when i do a sync with odx it’s succesfull, the transfer gives me for 4 files the message “ is used by another table”. all other files in the same map go ok.
have tried to recreate the blob container, and recreate the parquet files again, same results.
Exact message:
The table folder 'parquet_taak_status' is used by another table with the id 9a510177-a130-4bcc-aaaa-5abefd42c1b9
how to solve / find the other table that is referenced to?
Please go to the Azure portal, and try to delete the table level folder in the data lake for the tables that are giving the error. Then synchronize and transfer again.
worked finaly, thanks
Any plans to fix this? This is happening to me quite a lot and in some cases I don’t have access to the Data Lake so this can be a bit frustrating
Hi,
this can be pretty annoying indeed. It should be possible to do something similar to “Take ownership” in Deliver endpoints to resynch the extended properties for blob folders and files.
Bump :)
In some cases deleting the parquet files and starting all transfers again does not fix the issue though.
For some reason several of my ODX transfers stopped working last night.
After "Synchronize objects" all table mappings were gone.
The transfer tasks in the ODX were still successful and the parquet files in the ADLS Gen2 data lake were still there. But there were warnings like "The table folder 'rest_score' is used by another table with the id 60613c61-9788-4d0c-bb8d-4cd831858d03". I deleted all data lake folders an transferred all data again. That fixed the transfer tasks but the DSA mappings still failed.
It was a terrible pain in the *ss to fix all broken mappings (from ODX to DSA). Luckily I had an older TimeXtender project open on a different server so I was able to manually check all table mappings/field mappings.
Am I missing something? Why was TimeXtender (Classic, version 20.10.66) unable to fix these mappings? This was quite an expensive issue that took quite some time to repair.
@RLB what was the error message for the failing ODX transfers, do you know what caused them to fail? can you please explain what you mean by “The transfer tasks in the ODX were still successful”, when did they start succeeding again after failure, did you make any changes?
I mean that the transfer tasks themselves did not fail, but they succeeded with warnings. The warnings being the “in used by another table” message.
They started succeeding again after I had removed all file folders in the data lake like I mentioned above.
But the issue in the DSA was not fixed until I remapped all tables, because these errors did not go away:
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
