I'm comfortable with sqlite but when I use two different python program to access the same database. It throws an error like table is locked.
What are the different portable database to use with python?
SQLite is great but is designed as a small, fast, single user database. it isn't designed for the use you describe.
You can just pretty much any database with Python. The Python database API provides a straightforward way to interface with most relational databases, including SQLite.
However, to interact with a database in a more natural Python style, I've enjoyed using SQLAlchemy. It took a bit to work through the tutorial but it's great.
My personal preferred database is Postgres, but there are many other choices.
I developed an application in C, using MySQL. Now I wanted to migrate to Oracle, and don't want to make so many changes in code as well, like connecting to database and etc. 'liboramysql' a MySQL Client Library Driver for Oracle Database which is very useful in this case.
But a part of my entire code is written in Python as well, for which I need a similar lib or something similar to it. Is there any way to do this?
Say I have a database of recipes that I have online, and I want to use this database in a program, but I want to store the information from the database internally to the program and only have to connect to the online database when I want to update, however I don't want my end-users to have to have a database(MySql, MSSQL, etc..) installed to their machine. What would be the best way to efficiently do this?
sqlite is the most common way to use databases without a database server.
which is the best back end for python applications and what is the advantage of using sqlite ,how it can be connected to python applications
What do you mean with back end? Python apps connect to SQLite just like any other database, you just have to import the correct module and check how to use it.
The advantages of using SQLite are:
You don't need to setup a database server, it's just a file
No configurations needed
Cross platform
Mainly, desktops applications are the ones that take real advantage of this. For web apps, SQLite is not recommended, since the file containing the data, is easily readable (lacks any kind of encryption), and when the web server lacks special configuration, the file is downloadable by anyone.
Django, Twisted, and CherryPy are popular Python "Back-Ends" as far as web applications go, with Twisted likely being the most flexible as far as networking is concerned.
SQLite can, as has been previously posted, be directly interfaced with using SQL commands as it has native bindings for Python, or it can be accessed with an Object Relational Manager such as SQLObject (another Python library).
As far as performance is concered, SQLite is fairly scalable and should be able to handle most use cases that don't require a seperate database server (nothing enterprise level). An additional benefit of SQLite is that the database is self-contained in a single file allowing for easy backup while remained a common enough format that multiple applications can access the data. A word of advice on using SQLite with Python, however, is that you may run into issues with threading (in the past most of the bindings for SQLite were not thread-safe, although this may have changed over time).
The language you are using at the application layer has little to do with your database choice underneath. You need to examine the advantages of other DB packages to get an idea of what you want.
Here are some popular database packages for cheap or free:
ms sql server express, pg/sql, mysql
If you mean "what is the best database?" then there's simply no way to answer this question. If you just want a small database that won't be used by more than a handful of people at a time, SQLite is what you're looking for. If you're running a database for a giant corporation serving thousands, you're probably looking for Oracle. In between those, you have MySQL, PostgreSQL, SQL Server, db2, and probably more.
If you're familiar with one of those, that may be the best to go with from a practical standpoint. If you're doing a typical webapp, my advice would be to go with MySQL or PostgreSQL as they're free and well supported by just about any ORM you could think of (my personal preference is towards PostgreSQL, but I'm not experienced enough with either of these to make a good argument one way or another). If you do go with one of those two, my recommendation is to use storm as the ORM.
(And yes, there are free versions of SQL Server and Oracle. You won't have as many choices as far as ORMs go though)
I'd like to use the Python version of App Engine but rather than write my code specifically for the Google Data Store, I'd like to create my models with a generic Python ORM that could be attached to Big Table, or, if I prefer, a regular database at some later time. Is there any Python ORM such as SQLAlchemy that would allow this?
Technically this wouldn't be called an ORM (Object Relational Mapper) but a DAL (Database Abstraction Layer). The ORM part is not really interesting for AppEngine as the API already takes care of the object mapping and does some simple relational mapping (see RelationProperty).
Also realize that a DAL will never let you switch between AppEngine's datastore and a "normal" sql database like mysql because they work very differently. It might let you switch between different key value stores, like reddis, mongo or tokyo cabinet. But as they all have such very different characteristics I would really think twice before using one.
Lastly, the DAL traditionally sits on top of the DB interface, but with AppEngine's api you can implement your own "stubs" that basically let you use other storage backends on their api. The people at Mongo wrote one for MongoDB which is very nice. And the dev_appserver comes with a filesystem-based one.
And now to the answer: yes there is one! It's part of web.py. I haven't really tried if for the reasons above, so I can't really say if it's good.
PS. I know Ruby has a nice DAL project for keyvalue stores in the works too, but I can't find it now... Maybe nice to port to Python at some point.
Nowadays they do since Google has launched Cloud SQL