Add Named Database Connection: Named Connections store (in a central location) authentication information associated with a user.
For information about setting up and using named connections, please see:
The host name of the Microsoft SQL Server or Azure SQL Database. (It is not necessary to specify a port if a default configuration is used.)
If you have configured your Microsoft SQL Server database to use a non-standard port number, you can specify this port here.
The correct syntax is:
<HostName>,<port>
or
<IP>,<port>
The name of the database to connect to.
When connecting through a Windows user account, select Windows Authentication. The database can validate the account name and password using the Windows principal token in the operating system.
The user account is retrieved by Windows, so if you choose Windows Authentication, the Username and Password parameters are ignored.
Select SQL Server Authentication to proceed with specifying login credentials through the Username and Password parameters.
When Authentication is set to SQL Server Authentication, enter the username and password to access the database.
Note: This parameter is not present in the Azure SQL Database reader and writer. The Azure SQL Database reader and writer will always request Secure Sockets Layer (SSL) encrypted connections.
When selected, this parameter requests Secure Sockets Layer (SSL) encryption for the connection. If the server does not have a certificate trusted by the client machine, the connection will fail. Otherwise, data will be encrypted before traveling over the network. There are multiple ways to trust a server certificate on a client machine.
If this parameter is not selected, encryption behavior will be determined by encryption properties set for SQL Server Native Client, and for SQL Server.
Tip: When Encrypt Connection is selected, please provide a fully qualified Server name. For example, a server named safe-sql-server might have a fully qualified name of safe-sql-server.dev.safe. This fully qualified name should be an exact match for the server name on the trusted certificate.
Some parameters (including most Advanced parameters) are accessible only from the Workbench Navigator after you add a reader or writer to a workspace. The general hierarchy is shown below; however, the list order may change depending on the format. These parameters are not visible in the parameters dialog.
When set to Yes, this parameter changes the insert mode from feature-by-feature to batch. This can result in anywhere from six to ten times greater insertion speed. The compromise is reduced granularity in errors, with one invalid feature potentially causing the failure of a complete transaction.
The speed of the bulk insert will increase with transaction size (fewer transactions = faster insert). Larger transaction sizes also mean that if a transaction fails, there will be more rows to re-insert.
In Microsoft Azure SQL Database Non-Spatial (MSSQL_AZURE), Bulk Insert is very important as the insertion speed increase is on the order of 300x. However, for Bulk mode to work with Azure, the Server and Username parameters must be changed:
The remaining parameters can be left unchanged.
This parameter tells the writer when to start actually writing features into the database. The writer does not write any features until the feature is reached that belongs to the last successful transaction +1.
Usually, the value specified is 0, which causes every feature to be output. . A non-zero value is only specified when a data load operation is being resumed after failing partway through.
This parameter sets the number of features to be placed in each transaction before a transaction is committed to the database.
A default value of 500 is used as the transaction interval.
If this parameter is set to 0, then feature-based transactions are used. As each feature is processed by the writer, it is checked for an attribute called fme_db_transaction. The value of this attribute specifies whether the writer should commit or roll back the current transaction.
The value of the attribute can be one of COMMIT_BEFORE, COMMIT_AFTER, ROLLBACK_AFTER or IGNORE. If the fme_db_transaction attribute is not set in any features, then the entire write operation occurs in a single transaction.
The time, in seconds, after which to terminate a query to the database if it has not yet returned a result. If set to zero, there is no timeout. The default is 30.
This parameter allows you to execute ad-hoc SQL before opening a table. For example, it may be necessary to ensure that a view exists prior to attempting to read from it.
Upon opening a connection to read from a database, the reader looks for the directive <ReaderKeyword>_BEGIN_SQL{n} (for n=0,1,2,...), and executes each such directive’s value as an SQL statement on the database connection.
Multiple SQL commands can be delimited by a character specified using the FME_SQL_DELIMITER directive, embedded at the beginning of the SQL block. The single character following this directive will be used to split the SQL, which will then be sent to the database for execution.
Note: Include a space before the character.
For example:
FME_SQL_DELIMITER ; DELETE FROM instructors; DELETE FROM people WHERE LastName='Doe' AND FirstName='John'
Multiple delimiters are not allowed and the delimiter character will be stripped before being sent to the database.
Any errors occurring during the execution of these SQL statements will normally terminate the reader with an error. If the specified statement is preceded by a hyphen (“-”), such errors are ignored.
This parameter allows you to execute ad-hoc SQL after closing a set of tables. For example, it may be necessary to clean up a temporary view after writing to the database.
Just before closing a connection on a database, the reader looks for the directive <ReaderKeyword>_END_SQL{n} (for n=0,1,2,...), and executes each such directive’s value as an SQL statement on the database connection.
Multiple SQL commands can be delimited by a character specified using the FME_SQL_DELIMITER directive, embedded at the beginning of the SQL block. The single character following this directive will be used to split the SQL, which will then be sent to the database for execution. Note: Include a space before the character.
For example:
FME_SQL_DELIMITER ; DELETE FROM instructors; DELETE FROM people WHERE LastName='Doe' AND FirstName='John'
Multiple delimiters are not allowed and the delimiter character will be stripped before being sent to the database.
Any errors occurring during the execution of these SQL statements will normally terminate the reader with an error. If the specified statement is preceded by a hyphen (“-”), such errors are ignored.