This section illustrates the database specific features which are available to you through configuration, either through the .config file of your application or through code. See the Application configuration through .config files section for the details about the configuration settings defined through .config files.
When you're using unique_identifier types for primary keys on SQL Server 2005 or higher, you can benefit from a feature called NEWSEQUENTIALID(). This feature allows you to auto-generate new GUIDs for your primary keys which are sequential, so they are friendly for clustered indexes. To use this feature in LLBLGen Pro, you have to specify as the default for the primary key field in the table definition: NEWSEQUENTIALID(). Furthermore, you shouldn't set the PK field to a new GUID value when you're saving the entity. The DQE will then let the database insert the NEWSEQUENTIALID() produced value and it's automatically retrieved for you into the entity's PK.
The LLBLGen Pro Runtime Framework supports LocalDB at runtime. To make sure the generated code works with the LocalDB database, the connection string has to be adjusted to match the requirements for LocalDB. Please consult the LocalDB documentation for this.
The runtime supports SQL Server 2012 sequence objects on pk and non-pk fields. There's no check for SQL Server 2012 compatibility, however the queries will fail on SQL Server instances which are not capable of working with SQL Server 2012 sequences. The generated INSERT queries look like (in the example, Field2 is sequenced)
SELECT @p2=NEXT VALUE FOR [schema].[sequence];INSERT INTO table (Field1, Field2, .., Fieldn) VALUES (@p1, @p2, .. @pn);
The schema name is taking schema name overwriting into account, so you can use the normal schema name overwriting (per call, equal to Oracle).
The SQL Server DQE is usable for a variety of different SQL Server versions, from 7 to 2012 and from CE 3.1 to CE 4.0. The SQL Server DQE uses a compatibility mode to determine for which database to generate th SQL so the SQL matches the supported features for the SQL Server version used. You can set the SQL Server DQE's compatibility mode in two different ways: using the application's .config file or use a code statement. For the application's .config file method, please see Generated code - Application configuration through .config files. For using the code method, please see for SelfServicing: Generated code - CommonDaoBase functionality and for Adapter: Generated code - DataAccessAdapter functionality.
By default the compatibility mode is set to SQL Server 2005 or higher.Setting the compatibility level has the following effect on the generated SQL
To be able to target SQL Server CE Desktop, you first has to create a SQL Server project.
Stored procedures aren’t supported on CE Desktop, although they might be generated into the generated code. LLBLGen Pro uses the normal SQL Server DQE assembly for query production for CE Desktop. You also have to specify the compatibility level for the DQE, to signal it that it has to generate queries for SQL Server CE. For more information about this compatibility level, please see Generated code - Application configuration through .config files.
To be able to connect to a SqlServerCE desktop database, one has to adjust the connection string, as this connection string is the one used to connect to the SQL Server catalog from which the LLBLGen Pro project was created. It has to have the format shown by the following example:
<add key="Main.ConnectionString" value="data source=c:\pathtodb\databasename.sdf;"/>
As SQL Server CE Desktop doesnt support multiple catalogs nor
multiple schemas, these features arent available. Also System.Transactions transactions aren’t supported. All other LLBLGen Pro native features, like dependency injection, validation, authorization etc. are supported.
Linq is supported with SQL Server CE Desktop v3.5 or higher, however there are limitations in SQL Server CE Desktop which make it a bit of a struggle. For example the lack of scalar query support can lead to a lot of errors at runtime because a scalar query in a projection or WHERE clause isn't supported by SQL Server CE Desktop.
LLBLGen Pro supports SQL Azure out of the box, at runtime. To make your application run on SQL Azure you have to do the following:
By default, the Oracle DQEs will use Ansi joins, i.e. LEFT/INNER/RIGHT OUTER JOIN syntax. To switch this off, and use join syntaxis like SELECT .. FROM A, B, C, you can switch this off by using a setting in the application's .config file. Please see: Generated code - Application configuration through .config files for the details.
It can be that your project's Oracle database schema is used by multiple applications, among them your LLBLGen Pro based software. This can give the situation that you've to deal with the situation that the schema is configured to use triggers to insert sequence values on row insert. To tell the Oracle DQE DQE of choice that this is the case, and thus that it shouldn't ask for a new sequence value when a new entity is inserted, you've to add a setting to the application's .config file. Please see: Generated code - Application configuration through .config files for the details.
It can be that your project's Firebird database schema is used by multiple applications, among them your LLBLGen Pro based software. This can give the situation that you've to deal with the situation that the schema is configured to use triggers to insert sequence values on row insert. To tell the Firebird DQE of choice that this is the case, and thus that it shouldn't ask for a new sequence value when a new entity is inserted, you've to add a setting to the application's .config file. Please see: Generated code - Application configuration through .config files for the details.