webERP Forum

Hi there, I noticed that the DB doesn't have any stored procedures -- and therefore SQL and error handling are done on a case-by-case basis.

Is there any particular rationale behind this? Most importantly, would it be beneficial to replace some of this with calls to stored procedures?

I would be willing to work on that.

I am hoping to implement webERP for a school, we already have a POS in .NET and a connected access DB for course management, which is also being migrated to .NET with a MySQL back-end. There will likely be another web portal for students involved at some point, and I'd like to make sure that we can track payments purely by hooking in to webERP instead of storing all that information separately. Of course, having database manipulations stored as processes both increases security and makes API's a whole heck of a lot easier. (I'm especially worried about consistency of DB operations, specifically as I'll need the POS system to be making journal entries directly into webERP)

Hi, the reason for the lack of stored procedures is that it has always been the policy of webERP that it should be possible to port it to other DBMS.

You should use the API for your POS and portal rather than updating the webERP DB directly

Thanks
Tim

(02-25-2014, 06:28 PM)Forums Wrote: [ -> ]Hi, the reason for the lack of stored procedures is that it has always been the policy of webERP that it should be possible to port it to other DBMS.

You should use the API for your POS and portal rather than updating the webERP DB directly

Thanks
Tim

There's no inherent conflict between stored procedures and porting, if you abstract the procedures behind a php function (like the API) and make that load whatever script/procedure is appropriate for the DBMS in use you don't even have to worry about it.

As it stands, the portal could potentially use the API but the other existing software can't.