112 DATABASE ACCESS Clause Examples for Any Agreement

DATABASE ACCESS. 44.3.1 SBC13STATE shall provide to CLEC nondiscriminatory access to databases and associated signaling necessary for call routing and completion pursuant to the applicable Appendix UNE, which is/are attached hereto and incorporated herein by reference.

DATABASE ACCESS. OACP agrees to provide access to its new, modernized consumer complaint system to State Attorney General employees involved in implementing this MOU when OACP determines that enforcement may be warranted based on information submitted by the State Attorney General. State Attorney General employees will need to comply with security requirements for its use and agree to protect personally identifiable information (PII) contained in the system in accordance with all applicable statutes, including but not limited to the Privacy Act of 1974 (5 USC 552a), regulations, directives, orders and policies. OACP’s new, modernized consumer complaint system is expected to be operational in 2024.

DATABASE ACCESS. To the extent technically feasible, Ameritech will provide access to databases used in the provisioning of Operator Services via requesting carrier's Bona Fide Request.

DATABASE ACCESS. String-building is forbidden. An application should never piece together SQL statements from strings. This creates the risk of SQL injection. Note that string-building can occur inside stored procedures that use EXEC. Use stored procedures whenever possible. Stored procedures save the structure of the SQL query on the database. This is the best way to prevent SQL injection. It also offers advantages for organization, performance and granular authorization.‌ • If stored procedures are not possible, use prepared statements. Prepared statements safely separate SQL queries and parameter values. This effectively prevents SQL injection, but does not offer the other advantages of stored procedures.‌ • Each application must have its own database account. Applications may not share database accounts. Each account’s permissions should be tightly configured so that it can only access the appropriate databases, tables and procedures.‌ • Use stored procedures whenever possible‌ • File paths should be built with extreme caution. If any client-supplied input is used to construct a file name or path, use strong input validation. Beware of slashes, backslashes and periods. It should never be possible escape the intended directory. Validate using “white list” logic.‌ • Store data and report files outside the webroot. Do not allow users to directly request files for download or view filesystem directories. Have the application act as an intermediary. Data, report and other files for download or reference should always be stored outside of the webroot.‌ • Explicitly set permissions on created or uploaded files and directories. In general, files should be set read- only, and only by the web server’s user. Never allow a file to be created with any execute or world-write permissions.‌ • Validate uploaded files. Uploaded files should be checked for file size and type, and scanned for malware if necessary. Consider what would happen if someone uploaded a Word or PDF file with an embedded virus that was widely distributed.‌ • Security-related errors should throw exceptions. Use throw/catch for all security-related exceptions, such authorization failures.‌ • Security-related errors should be logged. See the Accountability section for more details.‌ • Technical details should never be displayed to users. Applications in production should not display verbose error messages that include stack traces, configuration data or other technical information.‌ • Display generic error messages‌ ...

DATABASE ACCESS. 2.1 Access to the LifeSeq(R) Database.

DATABASE ACCESS. In accordance with Section 271 of the Act, Ameritech shall provide Focal with interfaces to access Ameritech's databases and associated signaling necessary for the routing and completion of Focal's traffic. Access to such databases, and the appropriate interfaces, shall be made available to Focal via a Bona Fide Request.

DATABASE ACCESS. The database is accessible to all practicing forensic anthropologists and/or their students and interns. Request for access to FADAMA is reviewed by a FADAMA Board (comprised of SOFA members) in order to assure that the individual requesting access is affiliated with the field of forensic anthropology. General demographic information from a FADAMA user (education, years of casework, geographic region of employment) is requested for all forensic anthropologists that submit cases. However, it is important to note that all submitted cases are viewed/accessed for download as anonymous submissions to other users. Cases eligible for entry into FADAMA are restricted to current and past, non-historic, forensic/medicolegal, presumptively or positively identified cases where a forensic anthropological analysis was completed. Cases need not have a complete forensic anthropology estimation of the biological profile in order to be submitted (e.g. stature was not estimated), however, more comprehensive cases should ideally be given submission priority.

DATABASE ACCESS. ‌ Where applicable Vendor shall make the System database and server available to external monitoring tools, to be performed by the State directly, or through the use of authorized third party.

DATABASE ACCESS. CIC shall provide @TRACK with daily electronic access to SBC or other @TRACK Customer alarm history, statistical information and database as defined in the Exhibit C. RESTRICTED PROPRIETARY INFORMATION The information contained herein is for use by authorized employees of the parties and their affiliates hereto only and is not for general distribution within or for distribution outside their respective companies except by written agreement.