The knowledge base has an article that deals with the permission error on sp_OACreate when logging into MAS 500. Sage's recommendation is to allow all users to have access to this and other system stored procedures to correct the problem. That will work, but it is tedious and opens up a security hole where users now can create SQL scripts that can call DLLs which could be devastating if the user doesn't know what they are doing.
Now normally you wouldn't see this error on a normal set up following the instructions, so there is something in place that prevents the error in the first place. That something is the stored procedure that calls sp_OACreate.
If following the installation instructions Sage has provided, the SA (or someone with SA rights) should be the person that creates the MAS 500 database. SA by default has permissions to the system stored procedures such as sp_OACreate. During creation of the MAS 500 database, the install program grants execute permission to the ApplicationDBRole for the stored procedure that executes sp_OACreate, thus allowing non-sa users the ability to execute sp_OACreate in that context without the need to have the permission explicitly set.
Now if a person other than SA creates the MAS 500 database and they do not have the permissions to the system stored procedures, anyone logging into MAS 500 will get the sp_OACreate permission error.
The proper way to correct the problem is to change the DBOwner of the MAS 500 database to a person with SA rights using sp_changeDBOwner
In addition to that you will also have to run the following so the database has access to the system stored procedures which reside in the Master database:
EXEC sp_dbOption '[Problem Database Name]', 'Database chaining', TRUE
Changing the database owner to a person with SA rights and ensuring database chaining is set will correct the problem without compromising the security of SQL Server.