r(603) error

[Alejandro Gamboa]

I am estimating a rolling regression but when I use the option saving and the name of the file to be replaced I get the following error:

rolling _b _se, window(400) r keep(date) saving(\\SGMII1178348\sector_real.dta, replace): arch deltaTRM L.deltaTRM deltaREAL deltaCDS deltaPPC, earch(1/1) egarch(1/1) distribution(ged)

(running arch on estimation sample)
file "\SGMII1178348\sector_real.dta," could not be opened

[Marcos Almeida]

Hello Alejandro,

I wonder whether you did select the working directory before performing the rolling regression.

[Clyde Schechter]

One possibility is that the file already exists and is a read-only file, so you cannot replace it. Another possibility is that you don't have write-privileges in that directory. Another possibility is that some other application has opened the file and locked it. Those are the most common sources of this response.

[Alejandro Gamboa]

Hi Marcos I selected the working directory before performing the rolling regression.

Clyde, I have checked all these possibilities but still dont find the problem. I have write privileges and the file I want to replace it is writable. How can i check if other application has opened the file and locked? Thanks

[William Lisowski]

Note that the command specified in post #1 includes the option

saving(\\SGMII1178348\sector_real.dta, replace)

but the error message quoted says

file "\SGMII1178348\sector_real.dta," could not be opened

And now, before giving my stab at the answer, a request that before your next post, you please review the Statalist FAQ linked to from the top of the page, as well as from the Advice on Posting link on the page you used to create your post, looking especially at sections 9-12 on how to best pose your question. In particular, please read FAQ #12 and use dataex and CODE delimiters when posting to Statalist. Note how much more clearly the difference between the file path you specified and the file path Stata reported appears when presented in a CODE block. Now, back to the problem at hand.

The backslash character

\

has special meaning to Stata: it will prevent the interpretation of any following character that has a special meaning to Stata. I'm not a Windows user, so I cannot confirm my hypothesis, but I suspect that this is causing Stata to try to write the file into the SGMII1178348 subdirectory of your working directory, rather than the SGMII1178348 directory at the top level of your current working drive. Or something like that.

But all is not lost: Stata will allow you to use the forward slash character in path names on any operating system, and on Windows Stata will take care of doing what must be done to appease Windows. Try changing your option to

saving(//SGMII1178348/sector_real.dta, replace)

and see if that works.

Added in edit: On still closer inspection of your error message, it appears that Stata included the comma as part of your file name? Try changing your option to

saving("//SGMII1178348/sector_real.dta", replace)

and see if that works. One or the other or both changes ought to solve the problem.

[Marcos Almeida]

William gave an insightful advice and that will probably solve the issue.

That said, as I commented in #2, and considering Alejandro replied in #4 that he selected the "right" directory, I believe he could just use saving(filename.dta, replace), i.e., without the need to type extra commands.

[Alejandro Gamboa]

Thanks a lot for your comments. They were really helpful. Now the problem is not the file, now when I run the command rolling_b derscribed in #1 appear many x in red colour. I guess its an error. What could be the reason?

thanks

[Alejandro Gamboa]

Instead of estimating in #1 an egarch model I estimate a GARCH model and I do not get any error for the rolling_b command. How can I fix that? Or what does it mean?

[Marcos Almeida]

Well, hard to guess it. However, since the reason for the error message (at least, in my opinion) was basically the (missing) selection of the working directory, I believe you won't get such an error messages anymore, provided you stick to the "right" directory. That is really good news.

[Nick Cox]

My wild guess would have to be some of the ARCH model fits were failing. Hard to check without sight of the data.