Qualche suggerimento su come far funzionare Rails con un back-end Access?

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

Domanda

Tremo nel chiederlo, ma il mio cliente potrebbe non offrire altre soluzioni SQL (o simili a SQL).So che Access ha alcuni hook SQL;sono sufficienti per ActiveRecord di base?

Dopo:

Apprezzo tutti i suggerimenti per utilizzare altri database, ma fidati di me:Ho provato a convincerli.Esiste un elenco "approvato" e non è presente alcun database SQL.L'inserimento di qualcosa nell'elenco potrebbe richiedere più di un anno e questo progetto verrà completato in tre settimane.

È stato utile?

Soluzione

È un azzardo, ma c'è un Adattatore ODBC per ActiveRecord potrebbe funzionare.

Altri suggerimenti

Sembra che ci sia qualcosa come un adattatore di connessione Access qui: http://svn.behindlogic.com/public/rails/activerecord/lib/active_record/connection_adapters/msaccess_adapter.rb

Il file database.yml sarebbe simile a questo:

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

Ne pubblicherò di più dopo averlo provato con Rails 2.1

Un'altra opzione più complicata ma che potrebbe funzionare se fossi costretto a farlo, è scrivere un livello di servizi web RESTful che esporrà Access ai binari.Se presti attenzione alla progettazione, i servizi Web RESTful possono essere utilizzati direttamente da ActiveResoure che ti offrirà molte delle funzionalità di ActiveRecord.

Ci sono alcune cose strane in Access che potrebbero causare problemi e non so se ODBC se ne occupa.Se lo fa @John Topley ha ragione, ODBC sarebbe la tua unica possibilità.

  1. Vero in accesso = -1 non 1
  2. Access tratta le date in modo diverso rispetto al normale TSQL.
  3. Potresti avere problemi a creare relazioni.

Se scegli Access, probabilmente imparerai di più sul debug di AcriveRecord di quanto ti sia mai importato (il che potrebbe non essere una cosa negativa)

Maudite ha scritto:

Vero in accesso = -1 non 1

Non corretto.Vero è definito come non falso.Pertanto, se desideri utilizzare True in una clausola WHERE, utilizza invece Not False.Ciò fornirà una completa compatibilità multipiattaforma con tutti i motori SQL.

Detto questo, non è certo un problema, dal momento che qualunque driver tu stia utilizzando per connetterti al tuo back-end tradurrà correttamente True nelle clausole WHERE nel valore appropriato.L'unica eccezione potrebbe riguardare le query passthrough, ma in tal caso dovresti scrivere l'SQL all'esterno di Access e testarlo sul back-end e incollare semplicemente l'SQL funzionante nella visualizzazione SQL della query passthrough in Access.

Maudite ha scritto:

Access tratta le date in modo diverso rispetto al normale TSQL.

Ancora una volta, questo sarà un problema solo se non utilizzi i driver ODBC o OLEDB, che si occuperanno di tradurre Jet SQL in TSQL per te.

Maudite ha scritto:

Potresti avere problemi a creare relazioni.

Non sono sicuro del motivo per cui vorresti che un'applicazione Access alterasse lo schema del tuo back-end, quindi mi sembra un non-problema.

Dovresti davvero convincerli a consentire SQLite.È semplicissimo da configurare e funziona come farebbe Access (come un file posizionato accanto all'app sullo stesso server).

In primo luogo, tu Veramente voglio usare sqlite.

Nella mia esperienza, Access stesso è un mucchio di [redatti], ma il motore di database Jet che utilizza è in realtà piuttosto veloce e può gestire alcune query SQL piuttosto complesse.Se riesci a trovare un adattatore per binari che funzioni davvero, direi che starai bene.Basta non aprire il DB con il frontend di accesso mentre l'app rails è in esecuzione :-)

Se il tuo cliente è abbastanza analista da permetterti di sviluppare solo con un elenco di database approvati, potrebbe essere più preoccupato dal fatto che Il getto è deprecato e non riceverà più supporto da MS.

Questo potrebbe darti qualche argomento nella tua ricerca per utilizzare un vero database.Buona fortuna

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top