I shudder to ask, but my client might offer no other SQL (or SQL-like) solution. I know Access has some SQL hooks; are they enough for basic ActiveRecord?
Later:
I appreciate all the suggestions to use other databases, but trust me: I've tried convincing them. There is an "approved" list, and no SQL databases are on it. Getting something onto the list could take more than a year, and this project will be done in three weeks.
It's a long shot but there's an ODBC adapter for ActiveRecord that might work.
There seems to be something of an Access connection adapter here: http://svn.behindlogic.com/public/rails/activerecord/lib/active_record/connection_adapters/msaccess_adapter.rb
The database.yml file would look like this:
development:
adapter: msaccess
database: C:\path\to\access_file.mdb
I'll post more after I've tried it out with Rails 2.1
Another option that is more complicated but could work if you were forced to do it, is to write a layer of RESTful web services that will expose Access to rails. If you are careful in your design, those RESTful web services can be consumed directly by ActiveResoure which will give you a lot of the functionality of ActiveRecord.
There are some wierd things in Access that might cause issues and I don't know if ODBC takes care of it. If it does #John Topley is right, ODBC would be your only cance.
True in access = -1 not 1
Access treats dates differently than regular TSQL.
You might run into trouble creating relations.
If you go with access, will probably learn more about debuging AcriveRecord then you ever cared to ( which might not be a bad thing)
Maudite wrote:
True in access = -1 not 1
Not correct. True is defined as not being false. So, if you want to use True in a WHERE clause, use Not False instead. This will provide complete cross-platform compatibility with all SQL engines.
All that said, it's hardly an issue, since whatever driver you're using to connect to your back end will properly translate True in WHERE clauses to the appropriate value. The only exception might be in passthrough queries, but in that case, you should be writing the SQL outside Access and testing it against your back end and just pasting the working SQL into the SQL view of your passthrough query in Access.
Maudite wrote:
Access treats dates differently than regular TSQL.
Again, this is only going to be an issue if you don't go through the ODBC or OLEDB drivers, which will take care of translating Jet SQL into TSQL for you.
Maudite wrote:
You might run into trouble creating relations.
I'm not sure why you'd want an Access application to be altering the schema of your back end, so this seems to me like a non-issue.
You should really talk them into allowing SQLite. It is super-simple to setup, and operates like Access would (as a file sitting next to the app on the same server).
Firstly, you really want to be using sqlite.
In my experience Access itself is a pile of [redacted], but the Jet database engine it uses is actually pretty fast and can handle some pretty complex SQL queries. If you can find a rails adapter that actually works I'd say you'll be fine. Just don't open the DB with the access frontend while your rails app is running :-)
If your client is anal enough to only allow you to develop with an approved list of databases, they may be more concerned by the fact that Jet is deprectated and will get no more support from MS.
This might give you some ammunition in your quest to use a real database. Good luck
Related
My friend has setting up a database for a Ragnarok Online server, and he wants me to code the relative website, which is going to use some of that data (and obviously, i'll have to add tables for the news system, website accounts, etc). Since i'm learning RoR i was going to do it that way.
I have a few "best practice" questions related to this :
Should I create a different database for the website, since it's going to have its particular data alongside the game data ? (i already have a few clues to link multiple databases with Rails, but that seems too much of a hassle for what it is).
If not, do i have to create Model/Controller for each of the tables composing the database, despite the fact that i'm not going to use 90% of it ? Or just the ones that i need ?
An example of this problem : the game database has its own "user" table, but i have to have another "user" table for the website, and do some Joins between those two. So, what's the best practice here ?
Uhm, best practice is not making your own user table. This will cause you much pain. Best practice? Use an API. Expose the game's database in some way to your website, and fetch that info with external requests in your web application.
The reason why making a second user table is a hassle:
1) You'll constantly have to update it, pulling data from the original
to keep it up-to-date.
And I mean furthermore, you're gonna have to create a CRON job or something pulling data from that original table to keep it up to date. Yuck. Also what if that CRON job makes a mistake? (It will)
2) It's almost inevitable that there will be inconsistencies if two
separate tables are maintained. Are you sure your web application is
really fail-proof?
Update:
What you're gonna need is essentially a second Rails application that acts as a REST API for that database. For a good idea of what REST is, I'd read through this to get you started: http://tomayko.com/writings/rest-to-my-wife
Once you have a good understanding of that, start making your app, and test if it's working by using tools like cURL to send requests to your API.
Once you have that done, I'd take a look into the Ruby rest-client gem like Nobita mentioned. This is what you're going to use from your web application to request information from your API application.
Just let me note, I think this would be a terrible first Rails project, unless you're already really well versed in other web development tools, preferably MVC frameworks.
My site is written in ruby (rails) and it's very easy to persist the results of an offsite json feed with using jsondb, so I have an app that would benefit from this, but I think I'd like to keep the rest of the site running on postgrs
Would I be better off moving everything to one database (jsondb?) or does rails easily allow me to use multiple ORM's in the same app
# just notes, ignore if you like cos the answers are subjective
# Perhaps I should build two web apps?
Sometimes it is practical to use multiple databases.
I'd take a hard look at the tenacity gem, which was introduced recently as a way to manage multiple databases within Rails .. and even relationships between them.
It doesn't look like it currently supports jsondb, but given its architecture, it should be possible to write your own adapter (... and then contribute it back?)
It's really better to have only one database. If it's better to use postGresql use it or only jsondb.
Having more than one database can be complicated to understand where is really your data.
I'm getting into MVC and is wonderful, however, still need to decide what dabatase system to use. For many years my options have been:
1) MS SQL. For complex web applications. Example: A shopping cart or CMS.
2) MS Access. For smaller and simple ones. Example: a small product catalog, blog or news system.
I don't want to keep using Access, however, using SQL means using SQL Express if you don't want to pay more (my clients will not want) in SQL database hosting. But using SQL Express (when hosting supports it) get some some connection problems when many connections are opened (from your app and others hosted apps in the same pool).
I want to use LINQ, thats why now I'm forced to use MS SQL (express) in order to use LINQ2SQL.
Any suggestion on what database rather that MS Access or SQL Express can be used that doesn't require more hosting expenses? Otherwise I have to try Entities + MS Access. Thanks for your help.
Access is completely unacceptable for any website that expects to handle more than one user at a time.
http://www.15seconds.com/Issue/010514.htm
What are your requirements for the databse? Do you need it to be relational? How many simultaneous users are you expecting for your website?
I would either use MySQL or SQL Server Express.
Perhaps you can post the details of your SQL Server problem. We may be able to find a fix for it.
For most small to medium websites, I would definitely use SQL Express. Its free and within its remit, works just as well as SQL Server full version. We run innumerable websites with SQL Express.
Regarding Access, Access is no joke. It just depends how you use it. If I put #mattimus on a horse and told him to lasso a 450 kg cow (something I did on a daily basis as a kid), he too would be a joke. It's horses for courses, isn't it?
To dispell the Access misconceptions, that are based on ignorance and false snobbery, see:
Who Access really is (one very versatile cookie for a start)
Just don't use Access for a website. You don't need to. SQL Express is all you need.
You can use pretty much any database that you want with MVC. As other have suggested stay away from Access for web development.
SQL Server including the Express edition is a good candidate for small web sites. You can also look into MySQL and other cheap/free relational databases.
On an unrelated note, mi familia es de Merida Yucatan. :)
Like so many questions asked on SO, this one is like "how long is a piece of string?" You can't say really say what's appropriate except if you consider the environment.
For a read-only website, Jet/ACE can perform quite splendidly if you know what you're doing. Michael Kaplan's http://trigeminal.com is backed by a Jet database, but it's read-only. Back in its heyday, MichKa used to say he was getting 100K pageviews per day (or some number that was outrageously high, so far as I was concerned!).
But with a read/write site, you wouldn't be able to support nearly as many users.
That doesn't mean you could use Jet/ACE as the back end. If you have five users max, and it's an Intraweb app, you can be just fine with it.
I wouldn't want to use it myself, but it's not going to be a problem with user populations that are appropriate for the Jet/ACE database engine to begin with, and particularly if you manage your connections properly. Jet/ACE works better with a single shared connection than it does with constant opening and closing of connections (because of the overhead of creating and recreating the LDB file), so you have to code against it differently than you would with your standard server-based database.
Also, Michael Kaplan used to point out that via ADO/OLEDB, Jet was threadsafe, but via DAO, it was not. Use of ADO/OLEDB made it marginally acceptable as a back end for a web site, though I would tend not to choose it for anything other than a site that was very small or disposable, or where there were no options that were not outrageously expensive.
But the key point is that there is no blanket statement that can be made here -- whether it will work reliably depends entirely on the specifics of the environment in which you're using it.
Access is a joke. You should go with MSSQL, MySQL, or Oracle. I like MSSQL personally. Access is not designed to handle large operations and is ridiculously slow.
Can anyone explain to integrate the MYOB in rails application
Integration to MYOB is not as simple as it might look.
In order to integrate to MYOB, you have to install the ODBC drivers, have the MYOB application installed and have direct access to the MYOB company file.
what is your integration requirements and purpose?
the solution we choose to go for is to build a desktop app that will facilitate the integration between the web app and MYOB.
hope this helps.
You can, however the only way to really do this is with the MYOB ODBC driver. The way this driver works is that it uses the Myobp.exe as a middle man between ODBC and the .MYO file.
The MYOB ODBC driver presents a SQL interface to MYOB, however there are some caveats. It's not a real SQL interface to MYOB. The data you can get in and out is closely matched by the Import and Export functions that MYOB presents in the program itself.
For getting data out, with the ODBC interface you can write SQL queries, and even some SQL type functions can be in these queries, but you may occasionally come across some things that will catch you out.
For getting data in, the ODBC driver presents uses a schema of tables with the prefix "Import_", with these tables all you can do is import data and they will not return things like the invoice number you just imported. This also means you cannot update existing entries the same way you would expect with a real SQL interface.
However, some data imports will result in an update of existing data if some of the fields match. My experience with MYOB and it's ODBC interface primarily deals with getting sales orders from a system I wrote entered into MYOB, so certain things can be done.
I did write my first version of this system in Rails, however you can't use the standard Rails models without adjusting the way they work because Rails is very opinionated on how it expects the database to act.
More recently I re-wrote it in Clojure and used handwritten queries.
For multiline inserts (for example the lines of an invoice) MYOB uses a transaction as a wrapper to indicate what lines should be on the one invoice.
So your best bet if you want to use Rails, would be to avoid using the Rails models, and perhaps write direct SQL queries and interface to that with your controllers and views.
I can't get to my old code right now, but it's something along the lines of this:
def create_myob_invoice( iso )
# We can assume we have the job
# Now, for each iso line, we add an invoice
latest_invoice_number = Sale.find( :first, :order => 'InvoiceNumber DESC' ).InvoiceNumber.to_i
if latest_invoice_number
# We need to wrap it all in a transaction so MYOB knows they're all the one invoice
MyobDatabase.transaction do
iso.lines.each do |line|
new_service_line = ImportServiceSale.new
# Map iso fields to MYOB service sale fields
# e.g. suff like:
new_service_line.Description = "#{line.sDescription}"
new_service_line.save
end
end
end
end
You may also be able to find something to help over at: http://freelancing-gods.com/posts/talking_to_myob_with_ruby
(using Ruby on Rails and ActiveRecord)
In short: Is there some way how a model can use different DB schema for each request?
Why I need id: I have a working intranet application working for one company but I decided I would like to offer it to other companies. The Rails way would be to add company_id to each model and alway use this scope. But making separate DB schema for each company would make much more sense. Is there some standard way how to do it?
thanks!
What would be wrong with having a separate instance of your application for each company?
Adding company_id to all the models is absolutely the way to go. What you're talking about is very difficult to manage in the long haul, and it may be tricky to ensure the correct connection is used to store the correct data.
Although layering in differentiation like that is annoying, it can be done and proven in a fairly short period of time, and after that things will be easier to manage. With named_scope it is not hard to filter using attributes like that.
The simple alternative is to deploy the application more than once, with a different database.yml for each company, where the data is isolated on the application level, not within the application.
It would be easy to do this with Passenger (mod_rails) and a bit of shell scripting.