Alguma dica sobre como fazer o Rails rodar com um back-end do Access?

StackOverflow https://stackoverflow.com/questions/20054

Pergunta

Estremeço ao perguntar, mas meu cliente pode não oferecer nenhuma outra solução SQL (ou semelhante a SQL).Eu sei que o Access tem alguns ganchos SQL;eles são suficientes para o ActiveRecord básico?

Mais tarde:

Agradeço todas as sugestões para usar outros bancos de dados, mas confie em mim:Eu tentei convencê-los.Existe uma lista de "aprovados" e não há bancos de dados SQL nela.Colocar algo na lista pode levar mais de um ano, e este projeto será concluído em três semanas.

Foi útil?

Solução

É um tiro no escuro, mas há um Adaptador ODBC para ActiveRecord isso pode funcionar.

Outras dicas

Parece haver algo como um adaptador de conexão do Access aqui: http://svn.behindlogic.com/public/rails/activerecord/lib/active_record/connection_adapters/msaccess_adapter.rb

O arquivo database.yml ficaria assim:

development:
  adapter: msaccess
  database: C:\path\to\access_file.mdb

Postarei mais depois de experimentar com Rails 2.1

Outra opção que é mais complicada, mas que poderia funcionar se você fosse forçado a fazê-lo, é escrever uma camada de serviços web RESTful que exporá o Access ao Rails.Se você for cuidadoso em seu design, esses serviços da web RESTful podem ser consumidos diretamente pelo ActiveResoure, o que lhe dará muitas funcionalidades do ActiveRecord.

Existem algumas coisas estranhas no Access que podem causar problemas e não sei se o ODBC cuida disso.Se isso acontecer, @John Topley está certo, ODBC seria sua única chance.

  1. Verdadeiro no acesso = -1 e não 1
  2. O Access trata as datas de maneira diferente do TSQL normal.
  3. Você pode ter problemas para criar relacionamentos.

Se você acessar, provavelmente aprenderá mais sobre a depuração do AcriveRecord do que você gostaria (o que pode não ser uma coisa ruim)

Maudite escreveu:

Verdadeiro no acesso = -1 e não 1

Incorreto.Verdadeiro é definido como não sendo falso.Portanto, se você quiser usar True em uma cláusula WHERE, use Not False.Isso fornecerá compatibilidade completa entre plataformas com todos os mecanismos SQL.

Dito isso, dificilmente é um problema, já que qualquer driver que você esteja usando para se conectar ao back-end traduzirá corretamente as cláusulas True in WHERE para o valor apropriado.A única exceção pode ser em consultas de passagem, mas nesse caso, você deve escrever o SQL fora do Access e testá-lo em seu back-end e apenas colar o SQL funcional na visualização SQL da sua consulta de passagem no Access.

Maudite escreveu:

O Access trata as datas de maneira diferente do TSQL normal.

Novamente, isso só será um problema se você não usar os drivers ODBC ou OLEDB, que se encarregarão de traduzir o Jet SQL em TSQL para você.

Maudite escreveu:

Você pode ter problemas para criar relacionamentos.

Não sei por que você deseja que um aplicativo do Access altere o esquema do seu back-end, então isso não me parece um problema.

Você realmente deveria convencê-los a permitir o SQLite.É super simples de configurar e funciona como o Access faria (como um arquivo próximo ao aplicativo no mesmo servidor).

Em primeiro lugar, você realmente quero usar sqlite.

Na minha experiência, o próprio Access é uma pilha de [redigidos], mas o mecanismo de banco de dados Jet que ele usa é realmente muito rápido e pode lidar com algumas consultas SQL bastante complexas.Se você encontrar um adaptador de trilhos que realmente funcione, eu diria que você ficará bem.Apenas não abra o banco de dados com o frontend de acesso enquanto seu aplicativo Rails estiver em execução :-)

Se o seu cliente for anal o suficiente para permitir que você desenvolva apenas uma lista aprovada de bancos de dados, ele poderá ficar mais preocupado com o fato de que Jato é depreciado e não receberá mais apoio da MS.

Isso pode lhe dar alguma munição em sua busca para usar um banco de dados real.Boa sorte

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top