This content has been marked as final. Show 8 replies
I remember a related discussion about this some time ago. Relative paths are picked up from the setting, rather than the parent-script's location. No idea if development is planning to fix this.
So anyway, specifying the path should be the solution. Don't know why you and your colleagues are getting different behaviour though...
Hope that helps,
Edit: How about using *@@* instead of just *@* ?
Edited by: -K- on 03/08/2009 13:18
That's your problem. I have a number of scripts that call other scripts. When you pass scripts like this on to others, you should tell them to add the path of the starting folder for all the scripts. You can use @ or @@ or start to run these files. You do need to set the start path preferences as described in this thread.
You can use @ or @@ or start to run these files. You do need to set the start path preferences as described in this thread.Sorry Sue but my problem is this.
I have just run two scripts
Script #1 has this statement
which in turn calls this
Script #2 has this statement
which in turn calls this
Now those two scripts - apart from the obvious - seem identical to me. So why does script#1 succeed and script#2 fail with
This is just plain inconsistent.
Unable to open file: "C:\sqldeveloper\sqldeveloper\bin\E:\blah\blah\blah\DatabaseCreateScripts\install\../db_objects/alt_lkup_lt.sql"
All my scripts call other *.sql scripts, so even though there is the obvious difference, this is not the issue. Other than that - you don't provide enough detail for me to help. I run scripts that call scripts all the time. It would be good to try to track this down, as I think this is a key feature in the worksheet.
Can you tell me the release you're running? I'll try some tests there.
I'm using 1.5.4
I fired up SQL D today, opened the files and they ran without a problem. Which is irritating to say the least (well actually it's good news but in the context of this thread it's irritating). My current hypothesis is that maybe the order in which the files get opened or get run has an influence. Or it may be something ambient like memory usage. Certainly explicitly setting a the worksheet default directory parameter seems to solve it. It's just unfortunate that we have two separate directories, install and regress, which get used a lot we want the developers to rebuild the schemas constantly (a poor man's CI).
We have also been problems with getting the scripts to run in SQL*Plus. It seems the Oracle client is very sensitive to where you start it from, and basically it doesn't honour the @@ notation.
Ok, well I guess that's a good news bad news story. It is important that you set the directory explicitly in SQL Developer. The good news is the scripts have now both worked. The bad news is that they did not appear to work when you tried them before (can you concede a typo perhaps?) Also that the @@ is not as you would like. So we have an ER to log on that.
I'm sure we all have areas in the product that are important and this is one I use a lot, because I'm forever rebuilding my test environment, so when my scripts fail, I'm not happy. ;-)
Within the parameters of setting that directory, if indeed you are running into inconsistencies. Let us know.