I just picked up a new client that needs a database to store sales leads information, but his comfort level is Access and Excell - ugh!!

I wanted to keep it open source and keep it open for mobile access through SQLite, maybe even tinker around with some RubyOnRails.

Anybody have any thoughts on me taking the time and trouble to integrate an access database or just bring them up to speed on their db platform???

So either you persuade someone the benefits of what you are proposing (and benefits for the customer not benefits for you or your CV), or do it the way the customer feels comfortable with, or don't do the job.

after all its the customer paying the bills, its the customer that will have to use your app, and possibly maintain it over the years should you move on.

there is no reason why you can't use an open source db like MySQL.... heck I wouldn't be surprised if you could use SQLite within Access. If you are competent in db Design then using something like access shouldn't be a barrier. It could be if the customer wants to deploy the sales leads to say remote devices, or wants to support significant numbers of concurrent users. but again access front end talking to a server back end isnt a problem.. its access front end talking to jet thats a problem.. and Im guessing you'd have similar problems with SQLite

But at the end of the process.. is you preference for Ruby or whatever down to you improving your CV or of genuine benefit to your customer. If your current skill sets aren't compatible with the job in hand then either you have to a pass on the job or find a work around.

Give him a SQL Server back-end, with a Microsoft Access Data Project front-end as an interface. This will keep him in his comfort zone, and allow you to scale up in the future.

I concur. Access can be very effective when used with SQL (or MySQL) and then he can still create reports and forms without needed your hand holding. The biggest problem with upgrading is that people really don't want to hand over complete control and hesitate on project completion because of it. It's important that you don't become their sole support on the database either.

I've never had much success with SQLLite, and prefer MySQL instead. SQLLite just doesn't seem as sturdy or well supported.

SQLLite seems fine as far as I can see, but it has similar weaknesses to JET, heck some may argue its an open source/multiplatform alternative to JET. In my view if the appliciation cannot use JET then Id skip SQLLite and go straight to a server.

We did deploy an app with SQLLite a while back..... the customer wanted a web based app but wasnt prepared to pay for another server product (MySQL had been ruled out because a mate of a mate said it was terrible). Seemed to work fine.. I wouldn't want to rush and use it again mind you.