Aplicação deixar de funcionar quando se fala de oráculo a menos caminho executável contém espaços

https://stackoverflow.com/questions/239622

04-07-2019
|

Pergunta

Nós temos um problema-arquivos x com nosso aplicativo .NET. Ou melhor, aplicação Win32 e .NET híbrido.

Quando se tenta se comunicar com Oracle, ele só morre. Desaparece. Vai para o grande vazio negro no céu. Nenhuma mensagem de log de eventos, sem exceção, sem nada.

Se nós simplesmente pedir a aplicação de falar com um MS SQL Server em vez disso, que tem o efeito de substituir o uso de OracleConnection e classes relacionadas com SqlConnection e classes relacionadas, ele funciona como esperado.

Hoje tivemos um grande avanço.

Por alguma razão, um cliente tinha descoberto que, colocando todos os arquivos do aplicativo em um diretório em seu desktop, ele funcionou como esperado com a Oracle também. Movendo o diretório até a raiz da unidade, ou em C: \ Temp ou, bem, um pouco, fez a reaparecer acidente

Basicamente, foi de 100% reproduzível que o aplicativo funcionou se executar a partir diretório no desktop, e não conseguiu se executar a partir diretório raiz.

Hoje nós descobrimos que a diferença que contava era wether havia um espaço no nome do diretório ou não.

Assim, esses diretórios iria funcionar:

C:\Program Files\AppDir\Executable.exe
C:\Temp Lemp\AppDir\Executable.exe
C:\Documents and Settings\someuser\Desktop\AppDir\Executable.exe

Considerando que estes não faria:

C:\CompanyName\AppDir\Executable.exe
C:\Programfiler\AppDir\Executable.exe      <-- Program Files in norwegian
C:\Temp\AppDir\Executable.exe

Eu estou esperando que alguém lendo este tem visto um comportamento semelhante e ter um "aha, você precisa mexer o FROB da configuração do driver Oracle brilho" ou similar.

Qualquer um?

acompanhamento # 1: Ok, eu processado a saída procmon agora, ambos os arquivos a partir de quando eu acertar o botão que as tentativas para abrir a janela que desencadeia a falha em cascata, e tenho notado que eles mantenham rastrear sua maioria, há algumas diferenças bem pequenos perto do topo de ambos os arquivos, e eles mantêm rastrear um longo caminho para baixo.

No entanto, quando uma corrida falhar, o outro continua indo e das próximas linhas da saída de log são os seguintes:

ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll    SUCCESS    Offset: 274 432, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll    SUCCESS    Offset: 233 472, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O

Depois disso, o prazo de trabalho continua a executar, e outros toques do mscorwks.dll arquivos algumas vezes antes de tópicos fechar e as fecha de aplicativos. Assim, a corrida falhou não toque a acima arquivos.

Dar seguimento # 2:. Pensei em tentar atualizar os drivers de cliente Oracle, mas 10.2.0.1 é, aparentemente, a versão mais alto disponível para clientes do servidor e XP do Windows 2003

Dar seguimento # 3: Bem, nós acabamos com uma solução de caixa-preta. Basicamente, descobrimos que o problema está em algum lugar relacionado com XPO e Oracle. XPO tem um sistema de mesa que gere, chamado XPObjectType, com três colunas: Oid, TypeName e AssemblyName. Devido à forma como a Oracle está configurado nas bases de dados que falamos, os nomes das colunas eram OID, TYPENAME e assemblyName. Isso normalmente não seria um problema, exceto que fala XPO para as informações de esquema direta e verifica se a tabela está lá com os nomes coluna da direita, e não XPO não lidar com as diferenças de caso para que ele vê uma mesa XPObjectType com três colunas desconhecidas e nenhum daqueles que espera.

Exatamente o XPO faz agora eu realmente não sei, mas se eu cair esta tabela, e recriado-lo com o caso direito, usando aspas duplas em torno de todos os nomes das colunas para obter o direito caso, o problema não colheita -se.

Exatamente onde o espaço no nome da pasta vem a este, eu ainda não tenho idéia, mas este problema tinha dois níveis:

Parar o aplicativo falhando em nossos clientes, solução de curto prazo
Corrigir o erro, solução de longo prazo

Agora tier 1 é resolvido, nível 2 será colocado de volta na fila para agora e priorizados. Estamos enfrentando algumas mudanças maiores para a nossa camada de dados de qualquer maneira assim que este pode não ser um problema que precisamos resolver, pelo menos, se todos os nossos clientes Oracle verificar se a mesa-fix realmente se livrar do problema.

Eu vou aceitar a resposta por Dave Markle desde que Process Monitor (o irmão mais velho do Monitor de Arquivo) não chegou a identificar o problema, eu era capaz de usá-lo para determinar que depois da minha ponto de interrupção no user-código onde XPO tinha construído o consulta para esta tabela, não I / o que aconteceu até que todas as entradas para o baixo de fechamento aplicativo foi registrado, o que me levou a acreditar que era esta tabela que foi o culpado, ou pelo menos influenciado o problema de alguma forma.

Se eu conseguir chegar à verdadeira causa disto, eu vou atualizar o post.

Solução

Aqui está o que eu faria. Primeiro, TRIPLE-cheque que você está vendo o comportamento que você acha que você está vendo. Eu posso ver isso acontecer o contrário, não utilizando System.IO.Path a caminhos concatenar, mas não como você está vendo isso. Triple-Verifique se as permissões de arquivo faz sentido.

Em seguida, transfira Filemon de MS e ver o que está acontecendo na o sistema de arquivos como o programa atinge esses pontos problemáticos. Você pode filtrar a atividade de arquivo específico (remoção de sua atividade de arquivo de anti-vírus, por exemplo) para fazer tudo olhar um pouco mais limpo enquanto você faz isso. Procure por erros de acesso a arquivos usando FileMon, tanto para o caso de sucesso eo caso de erro para o seu programa. Isso deve apontar-lhe o arquivo está sendo acessado e causando o problema. Por exemplo, se você vir um erro FILE_NOT_FOUND acessar um nome absurdo, você pode ter certeza que você ou o vendedor está fazendo algo errado, possivelmente levando para o seu problema ...

Outras dicas

Você provavelmente deve ver se você pode reproduzir o problema com uma aplicação simples que apenas tenta abrir uma conexão com Oracle. Dessa forma, você pode ter 100% de certeza que o problema é com OracleConnection ou o driver Oracle e não com o seu próprio código.

Você deve obter uma medalha para a perseverança para isso!.

"Exatamente o que XPO faz agora eu não faço realmente sei, mas se eu cair este mesa, e recriado-lo com o direito caso, o uso de aspas duplas em torno de todos os nomes das colunas para obter o caso direita, o problema não surgir.

Exatamente onde o espaço na pasta nome vem a este, eu ainda não têm ideia "

As questões que recebo com espaços em nomes é que eles geralmente interpretar a pouco antes do espaço como o nome eo resto como um parâmetro. Se for esse o caso, então com o nome simples que pode ver "C \ Temp" e é um diretório. Com o nome espaçados, torna-se "C: \ Program Files", olhares para "C: \ Program" e que não existe. Ele iria falhar, por exemplo, para substituir "C: \ Temp", mas teria sucesso por escrito "C: \ Program". Se perguntam se ele ainda seria um fracasso com "C: \ Arquivos de Programas" se houver um arquivo ou diretório chamado "C: \ Program"

GOSTARIA suspeitar que o cliente Oracle para ser honesto. Teve um problema que foi semelhante em IT'S natureza frustrante.

Se instalado em máquinas de 64 bits o cliente iria parar no início, quando a conexão com a Oracle, mesmo que o aplicativo é 32 bits. Nós finalmente rastreado-lo para baixo para o fato de que um determinado cliente Oracle (Ora 10 teve um problema com colchetes no caminho para um programa em execução no arquivos de programas funcionaria sob Program Files (x86) causou o acidente. Atualizando a máquina para usar o 11G cliente resolveu o problema mas também houve alguns patches disponíveis a partir metalink que não estão diretamente disponíveis. o que é estranho no seu caso é que você começa sem exceção, mas o comportamento de mover o aplicativo para uma nova correção de pasta a questão de forma semelhante por isso podem ser relacionados.

ORA-12154: TNS: poderia não resolver o identificador de conexão especificado ou ORA-6413: Conexão não abrir.

http: / /blogs.msdn.com/debarchan/archive/2009/02/04/good-old-connectivity-issue.aspx

Detalhes do Metalink abaixo.

Metalink Bug 3807408 não pode usuário externamente autenticar com citações em nome de usuário

Descrição Se um nome de utilizador autenticado externamente contém um '(', ')' ou '=' em seguida, o usuário não pode ser autenticado. Além disso, se um nome de programa / path contém esses personagens que pode não ser possível se conectar. por exemplo: clientes Windows instalado em um diretório "C: \ Program Files (x86)" não conseguem se conectar com ORA-12154: TNS: não foi possível resolver o identificador de conexão especificado

A marca deste problema é que o traço Net (16 nível) mostra o caráter problema / s substituído por um "?" no rastreio.

Solução Para o problema de autenticação: mudar nome de usuário, ou não utilizar a autenticação OS remota para os usuários

Para a emissão do programa / diretório: mudar o nome do programa / diretório

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow