No - nobody can perform SQL queries from within the Dynamics GP application, and nobody can use their GP login and password to log into SQL - the password of your SQL login is encrypted with a strong encryption.

"As the parent mentions, NO USER has DB access in an ERP system. Only the ERP system itself has access and then the ERP system manages all table and transaction access. Can anyone verify this for GP? Also, even if the system password is available to any user created in GP I don't think that matters." As far as Dynamics GP is concerned, all users set up in the system have full read/write access to all tables. The security layer comes from the encryption of the users' passwords by GP for their SQL login. This is done using a strong encryption method, not a caesar cypher. The original poster, I think, caused a bit of a stir here because I think 101 people here are mistaking the "system" password (which is a weak security password for opening certain system windows, of which all of them would be locked down by the normal security in GP anyway), and the 'sa' password, which truly does have "god" powers in the system.

..Apparently you're new to the whole ERP system thing.. A few pointers: 1. The system password uses weak encryption because it is a weak security measure and isn't meant to secure sensitive parts of the system. 2. Very little data is encrypted at all in the database, as is the case with most ERPs. This is because such encryption would be impractical for systems that are by their very nature "open" to third party developers.. Dynamics GP itself has thousands of third-party add-ons that access the database directly, and there are thousands more stand-alone applications that must access the database.. if the DB were encrypted, everyone would need the key, in which case the encryption wouldn't mean squat anyway. 3. The database is secured the way DB's are supposed to be secured - by having the proper roles defined for the DBs. The Dynamics GP DB's are inaccessible to anyone who does not have a login and the DYNGRP role. Now all Dynamics GP users have this role and can access the whole SQL server, but their passwords are encrypted so they cannot log in from anywhere but the GP system itself. This encryption is not the "substitution algorythm" that you describe. 4. If you're the DBA of a company running Dynamics and just discovered the above traits of Dynamics GP (hint, it's been that way for over 20 years), do yourself and your company a favour and stay far away from the Dynamics databases - you have NO BUSINESS touching the SQL server on which this data resides, unless you're simply setting up a backup or configuring new hardware. Your company will likely have a Dynamics GP partner to take care of the rest.

The business world will eventually learn that hacks throwing together craplets costs them far more time and money then a few talented developers doing it right the first time. Or they will continue to throw money at the problem, expecting that just getting 30 warm bodies that know how to press the right buttons in the right IDE will be a good strategic plan. Chances are the truth won't be realized until they go out of business.

Actually, I am a project manager in the "real business world".. I can tell you where the "craplets" come from, and it's not the programmers using the IDEs, it's those "pureists" that refuse to use the tools given to them.. Sure, their syntax is perfect and they know the language.. Hell, they might even know how to allocate memory to a program under MS-DOS without causing fragmentation with a nifty little assembly APP, but none of that makes a multi-million dollar project succeed - it is the programmers that can collaborate properly and follow a project plan as given to them from me.. (no, CVS and makefiles don't do this - logical project mangement does this - something better handled by an IDE than by a bunch of files thrown into a bunch of folders)..

The IDE assists in dealing with a project's assets properly as well as code-completion and debugging.. This way programmers can spend more time on learning algorythm efficiency, proper encapsulation techniques and modularization and, above all, efficient programming techniques.. There's no reason an IDE has to get in the way unless it is seen as a simple tool like a screwdriver, not a complex tool like a nuclear reactor.