B
bbrennan
Guest
I agree with everything Stefan has reported. We too have very similar issues. Our typical use case is a customer with an OE application from some other vendor. The end customers typically have little to no IT help on site. They have at best minimal knowledge of the Progress database and no knowledge of SQL. At some point, someone decides to use a SQL reporting tool like Crystal and then heads down the path of SQL users, permissions, GRANTing and REVOKEing. They also stumble on the command line mess that is SQLEXP. Using SQLEXP for very large scripts is taxing since you have no feedback on where it is or what it is doing. It is as likely not to work based on the locking Stefan described. I am not aware of any mechanism that will predict if my script will run cleanly without hitting a lock. That then leads to needing to kick everyone off a production server just to implement the proper updates. If you find you made a mistake, head back to the start and re-do it again including perhaps taking the server back from the users. TS may suggest using a third part tool like WinSQL. Very nice looking tool but the syntax required for a script is different than what you would feed SQLEXP. Both WinSQL and SQLEXP assume you are able to connect to the database as a DBA. That is not always a valid assumption. There remains a great deal on confusion still about the default DBA account SYSPROGRESS and the need to replace it with a user defined DBA privileged account. The security models between OE and SQL are opposite of each other. It would be spectacular to have a single tool to administer security in both realms. Lastly, this typically gets set once, after a lot of mistakes and rework, to the point that it finally supports running Crystal. Flash forward 3,4 or 5 years and the VAR/reseller builds a new server most likely not including any of the SQL bits. All of this repeats again on how to migrate SQL users and permissions to the newly built or upgraded database. Lastly, the user name that created the database may not actually be a a valid user on the end user's system. 'Chuck' from the reseller company may create and then zip up the new structures to send to the end user. The end user has no idea of 'Chuck's' credentials. A valid but flawed (IMO) solution is to create a _User record for SYSPROGRESS/SYSPROGRESS. It has always struck me as a bit of a security hole being able to do this and then gain access to the entire SQL side of the database. This problem is like getting sand in your eye. It won't kill anyone but is sure is irritating every time.
Continue reading...
Continue reading...