OpenERP - Not always so easy on Wiindows ? Login and SQL permission

Today, I am spending a bit of time on simple quotation, ordering, invoicing. To my great surprise I crashed the app in various simple screens of the application.

The point is: it works on Linux install but not on Windows. I am wondering why and investigating. I think the All in One install is not the latest code... Not sure yet.

Because each DB/Install becomes quickly different as modules are installed. I tried to backup the failing DB on Windows then restoring it on my Linux machine.

Sound simple... but it failed immediately... with a message popup "Couldn't backup database" .

I then stopped the Windows service and started the service in its command box -- a trick I recommend to everybody as you will see a good quantity of messages to debug your install... The exe is : openerp-server.exe

There, I could see that the server is prompting for a password!

This is the password used by Application server to connect to the Postgres database. By default the user is 'openpg' and password 'openpgpwd'. Once the password is entered the DB backup is executed in a few seconds.

Here is what you see when attempting to backup a DB from the Open ERP client:

432 user=openpg password=xxxxxxxxx dbname=template1', closed: 0>
Password: openpgpwd

Practically for my Open EPR that's it.

Looking at many applications, this single user scheme is frequent and may raise some questions. DBMS provide complicated authentication and validation schemes and application designers spend their time to shortcut these...

But don't think I am blaming the application deigners, they are just facing difficult time with inappropriate DBMS technology. Mapping one application user to one DBMS user is a pain:

• Most application want to connect to the DB to get application config that sits in the DB before asking a username to the user.
• Optimization like connection pooling are better implemented with one common user.
• There is no concept of SQL inpersonnifcation - (e.g Windows run as / Unix sudo).
• Security scheme is nice in DBMS but usually not enough for applications that are not expressed as stored procedure.
• Implementing permission on Business app is often driven by the data - e.g: cannot touch invoice of another office - that are difficult to implement at the DBMS level. So applicaitons developpers prefer a scheme that work for all permission issues.
• Error code and messages returned by DBMS are not easily map to business concept.
• Any more ?? Probably.

I see there two approaches to improve things (on the long run):

• Removing all this permission crap in DBMS that is not that much used (and that very often creates installations problems)
• Merging completely the application server with a DBMS. So that application code can benefit from DBMS permissioning.

However I know that the trends on the market is to add things and not to remove any. So I doubt somebody will remove the useless things (with the probably correct argument that may be somewhere somebody is using this feature).

The second option would hit the current market conception about generally accepted software layers. Again too bad for me. But remark that these layers in software do not correspond to a business scheme but to the IT sofwtare market structure...

I admit that there is little market pressure for such changes... so I will return to my OpenERP stuff.