Re: v$abc.. table names - nightmare

This is getting really silly.
Obviously I know how and when to escape special characters. Just because you can escape them, this doesn't mean it was a good idea to go and use them in table names.
Which bit are you not understanding exactly? I thought I had made this clear.

>
> If one is indeed in charge of writing and deploying script based
> monitoring solutions across so many different platforms and software
> architectures some basic scripting knowledge and competency is on the
> nice to have list.

Which I have, thanks very much. As I have already explained, I don't know the intracacies of every possible application I want to monitor. Hence the post.

>
> # What is more important for me is that the scripts follow a common
> standard - very specific STDOUT, STDERR and return code, respect a
> clearly documented set of environment variables, etc etc.
>
> One way to avoid "most" problems in querying oracle internal views/
> tables and ( especially ) some of the stranger x and v etc views is to
> put your code inside a sql file and executing that sql file.

Yes that has already been said and done earlier in the thread. Do keep up.
And by the way creating files can present its own problems, if you care about robust scripts.

> No reason that you cannot use that technique probably along with
> whatever other "common standards" that you are working from.
>
> On the other hand if you are really as handy at C++ as you say then
> you can also go directly at Oracle databases instead of driving file
> based monitoring solutions to and from the database instances.

Well you can. But this is code that a customer is very likely to want to customise. So a script is the best solution. Received on Wed May 18 2011 - 14:44:25 CDT