We moved a dataset
d to a new location. When we want to check the Original SQL from there, we got error message shows:
dataset d version 0000782655026442 at [/dataset/d/version/0000782655026442] not found
I think it didn’t move the
original sql to the new location. Is there a way I can find that under some folder?
Yes, I clicked that. Then I got error message shown above.
Sorry, I read your question wrong. . Ill defer to another Dremio expert on this one.
We would need exact steps to reproduce this such as how it was moved (from one space to another, or to a different folder, did the dataset get renamed?). Does opening the dataset work?
Yes, opening the datasets work. We moved dataset
Add Folder button. They are all in the same workspace. The
core is the workspace name.
Can you describe the dataset - is it a join of multiple datasets for example? Moving datasets works fine when I did a quick test so it might be something about our dataset’s composition.
- Create a table
test with statement like
sql.table01 is a physical table
- Save the table
- Change the SQL statement, make it like:
order by col
- Save the table
- Move the table to another folder, as described earlier
Original SQL button
- Error happen
@doron, in case it helps, I had a very similar issue with Dremio 2.0.1-201804132205050000-10b1de0.
I moved a couple of datasets derived from a MongoDB source from one space to another. After which I started to get the same error as @dli16 posted above when trying to open the source SQL of each of the moved datasets.
I did not have time to reproduce and report it, but learned to never move datasets and instead create a new one using a copy of the SQL statement.
@doron I am experiencing the same issue and as @muv states above, my only workaround is to copy the original SQL statement and create as a new query in the Space I would like to move to.
What I am wondering is, is whether this is the only option? as this could result in lost queries and it appears to me this makes the Move function harmful
What version of Dremio are you using? We have made several fixes to Edit Original SQL in 3.1 to make it more resilient.
Same problem here. There is any workaround to get this original SQL code?
3.2 should have no issues with original SQL, what version are you using?
You can also get the original sql by running
select * from INFORMATION_SCHEMA.views - the
VIEW_DEFINITION column will contain it.