OpenEdge Data Management: DataServer for Microsoft SQL Server
OpenEdge Data Management: DataServer for Microsoft SQL Server
OpenEdge Data Management: DataServer for Microsoft SQL Server
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Data</strong><strong>Server</strong> components<br />
If you plan to use the <strong>Data</strong><strong>Server</strong> to send <strong>SQL</strong> statements directly to the data source using only<br />
the RUN STORED–PROCEDURE syntax and you do not expect returned data, you need not load data<br />
definitions into the schema holder. However, you must do the following:<br />
• Load the stored procedure into the schema holder.<br />
• Connect to an empty data source.<br />
However, the RDBMS stored procedures also supports s and Pro<strong>Data</strong>Set functionality which<br />
does support returning data to the <strong>for</strong>eign data source. For in<strong>for</strong>mation on using RUN<br />
STORED–PROCEDURE, see Chapter 3, “RDBMS Stored Procedure Details.”<br />
Security<br />
Using the <strong>Data</strong><strong>Server</strong> <strong>for</strong> MS <strong>SQL</strong> <strong>Server</strong> involves following the security guidelines required<br />
by both the <strong>OpenEdge</strong> database and the MS <strong>SQL</strong> <strong>Server</strong> data source. By default, <strong>OpenEdge</strong><br />
security allows unrestricted access to data sources, so at a minimum, you should follow the<br />
guidelines that the data source requires <strong>for</strong> your applications.<br />
<strong>OpenEdge</strong> security<br />
The <strong>OpenEdge</strong> database management system has no minimum security requirements. You can,<br />
however, impose security features on any <strong>OpenEdge</strong> database or schema holder. There are four<br />
levels of application security that you can impose:<br />
• <strong>Data</strong>base-connection security<br />
• Schema security<br />
• Compile-time security<br />
• Runtime security<br />
For more in<strong>for</strong>mation about compile-time and run-time security, see <strong>OpenEdge</strong> Deployment:<br />
Managing ABL Applications. For general in<strong>for</strong>mation about <strong>OpenEdge</strong> security, see <strong>OpenEdge</strong><br />
Getting Started: Core Business Services.<br />
MS <strong>SQL</strong> <strong>Server</strong> database security<br />
As noted previously, you should follow the security guidelines that your MS <strong>SQL</strong> <strong>Server</strong> data<br />
source has established <strong>for</strong> your applications. The MS <strong>SQL</strong> <strong>Server</strong> database might require that<br />
all users supply a valid login name and password to access it. <strong>Data</strong> source access security<br />
typically has four levels:<br />
• System administrator — Grants or revokes permissions to other users to create or own a<br />
wide type of objects; <strong>for</strong> example, databases<br />
• <strong>Data</strong>base owner — Grants other users permission to access or modify a database or its<br />
objects<br />
• <strong>Data</strong>base object owner — Defines a user who can be the owner of objects in a database<br />
owned by another user<br />
• Public owner — Allows access to public database objects by any users without restriction<br />
1–7
Change language