Unable to create a Project with deleted name

kumar_s · Post by **kumar_s** » Wed Mar 22, 2006 3:59 am

That is the problem, even FIX option gives the same result.

** '/path/Project' is not a DataStage account.

Items marked with a '**' are situations where VERIFY.SQL could not continue.

But Adminsitrator client cannot create an account with the same name.
Which gives the error of 'Schema already exist'.

Should I need 'DROP' in UV.SCHEMA?

ArndW · Post by **ArndW** » Wed Mar 22, 2006 4:27 am

Create a new dummy account and copy the contents into that path. Later on delete the dummy acount. Do not copy a live account.

kumar_s · Post by **kumar_s** » Wed Mar 22, 2006 4:39 am

ArndW wrote:Create a new dummy account and copy the contents into that path. Later on delete the dummy acount. Do not copy a live account.

Yes...
Buy creating a dummy project, and creating a dummy directory with the project2 name, and copying all the content of the dummy project directory to the proejct2 directry and inserting an entry into UV.ACCOUNT creates a valid entry.
Now it allows to delete from Adminstrator client.

pneumalin · Post by **pneumalin** » Wed Mar 22, 2006 5:29 pm

Kumar_s,
Could you please post all the steps fix your problem, so we can learn from it.
Thanks!

Please discard my wrong posting on the other thread - Insert new recrod to UV.ACCOUNT. My apology..

Pneuma.

ArndW · Post by **ArndW** » Thu Mar 23, 2006 2:26 am

Since this problem was caused by inadvertantly doing something that shouldn't have been done in the first place and many of the steps touched upon in this thred have the potential of breaking not only a single project but the whole installation I would not feel comfortable describing all these steps. I know that someone, sometime will look at some of the steps involving the VOC or UV_SCHEMA files, try them and need to re-install DataStage because of it ... and then state "But I read it on DSXChange..."

It reminds me of doing support work for an operating system called PRIMOS (a precursor to today's UNIX) and the command to format a disk used an octal/hex number to define the platters to format and it was possible to get that numbe wrong and format a part of a running partition. The command could only be called from the equivalent of root and after you entered all the details it would ask "Are you sure?" and you had to spell out "yes", then it asked again, "Are you really sure?" and once again you had to spell out the full answer. Only then would it go away and do its formatting work.

Yet we still got support calls from customers where they said "I mistakenly entered the format commands... Your software sucks and it's your fault I have 500 users who can't work until we reinstall the OS..."

pneumalin · Post by **pneumalin** » Thu Mar 23, 2006 9:01 am

Arnold,
Thanks for the advise. That's a very good advise.
I just thought the steps might come in handy when I've done something stupid and no where to go except rebuilding the server or the project.

An incident once happens to my environment when I am adding a new project to DS server in Administrator, a power shutdown strikes us. The project folder is created in DS server. It did not show in Administrator Project list as a valid project, and I cannot create a new project using the same name.
I would appreciate it if you can provide a series of safe steps to remove the bad project folder, so that I can create the new project using the same name.

Thanks!

ArndW · Post by **ArndW** » Thu Mar 23, 2006 9:35 am

From this thread you will have seen 2 places in the engine which might prevent an account from being re-used. The first is an entry in the UV.ACCOUNT file and the other is an entry in the UV_SCHEMA. Does your bad project exist in the UV_SCHEMA file (LIST UV_SCHEMA {projectname})?