Alguma dica sobre como fazer o Rails rodar com um back-end do Access?
-
09-06-2019 - |
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.
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.
- Verdadeiro no acesso = -1 e não 1
- O Access trata as datas de maneira diferente do TSQL normal.
- 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