Connectivity in DataFlex 19.0 John Tuohy

Improved Indexing Support

Indexes Unlike the embedded database, SQL can (and will) order data with as much (or as little) of an index as exists (even none) DataFlex 19.0 provides support for full, client and server-only indexes Server = exits on server, defined in .int file, requires restructure Client Only = defined in .int only, requires .int update Server Only = exists on server, not defined in .int, not usually changed Easy to manage indexes in the Studio Provides the basis for runtime temporary indexes

Runtime Temporary Indexes Index creation supported through database API (required restructure on server) Client-side indexes removed the need for a table restructure (.int only) We used the same capability to support indexes that are not stored in the .int file and only exist at runtime Uses the same interface, but not within a structure_start / structure_end Create_Index Set_Attribute DF_INDEX_NUMBER_SEGMENTS Set_Attribute DF_INDEX_SEGMENT_FIELD Set_Attribute DF_INDEX_SEGMENT_DIRECTION Delete_Index

Runtime Temporary Indexes // create a temporary index for State x City x Customer and return its Index handle Function StateCityOrdering Returns Integer     Handle hTable     Integer iIndex     Move Customer.File_Number to htable       Create_Index hTable at iIndex             Set_Attribute DF_INDEX_NUMBER_SEGMENTS of hTable iIndex to 3     Set_Attribute DF_INDEX_SEGMENT_FIELD of hTable iIndex 1 to (RefTable(Customer.State))     Set_Attribute DF_INDEX_SEGMENT_FIELD of hTable iIndex 2 to (RefTable(Customer.City))     Set_Attribute DF_INDEX_SEGMENT_FIELD of hTable iIndex 3 to (RefTable(Customer.Customer_Number))     Function_Return iIndex End_Function

Runtime Temporary Indexes Procedure StartReport Integer iOrder // use the temporary index Get StateCityOrdering to iOrder Set Ordering of oReport to iOrder Send Run_Report of oReport // delete the temporary index Delete_Index Customer.File_Number iOrder End_Procedure

Convert, Connect, Refresh and Reconnect

Convert, Connect, Refresh and Reconnect Convert is used to convert tables to a different database – usually embedded to SQL Connect is used for existing tables (most likely created outside of DataFlex) that are not yet part of your workspace Refresh is used for tables that are already connected in the workspace but whose definition has changed on the server Reconnect allows options for connected tables in excess of a simple refresh Skip tables already connected Use existing .int files to synchronize the definitions of connected tables Ignore existing .int files but reconnect while reusing the same file number Can be used to switch to managed connection Ids

Managed Connections

Connection Basics Establishing a “connection” is how you access SQL data in your application Specifies the driver, server, database, user credentials and table/schema, for instance… DRIVER_NAME MSSQLDRV SERVER_NAME SERVER=SWM-M3800\SQLEXPRESS;Trusted_Connection=yes;DATABASE=Chinook DATABASE_NAME Album SCHEMA_NAME dbo Defined for each table in your application Located in the .int file for each table Tables can use different connections Connections are also needed when using the tools (Studio, DataBase Builder and Explorer, etc.) and when using Embedded SQL

Connection Ids Connection IDs were introduced to our drivers long ago Connection IDs are simply an abstract way to refer to these connections by Id while defining the actual connection string elsewhere The Connection ID is used in table .int files… DRIVER_NAME MSSQLDRV SERVER_NAME DFCONNID=Chinook DATABASE_NAME Album SCHEMA_NAME dbo Connection Ids were hard to use They were difficult to configure and maintain They were not directly supported by the DataFlex Framework They were not directly supported by the DataFlex tools (Studio, Database Explorer, etc.)

Introducing the cConnection class The cConnection class will handle all connections for DataFlex CLI drivers (6.2 and higher) cConnection is class that creates a single, global object that allows you to Add / edit / remove Connection IDs Use Connection IDs in your table .int files Define connections IDs in a workspace connections .ini file Login to database servers via Connection IDs Make ESQL connections to servers via Connection IDs We refer to these as Managed Connections and they are fully supported (and used) across all the DataFlex tools and the application framework Managed Connections build on existing Connection ID concepts; think of this like “Connection IDs 2.0”

Managed Connections Managed Connections provide a complete interface which includes Defining (Adding / removing / editing) Connection IDs to a workspace Login / logout via Connection IDs Handling credentials, including user name and encrypted password Dynamic switching of connection string definitions while an application is running A very simple, high-level interface for standard usage A complete, lower-level interface for advanced usage Managed Connections make it easier for you to… Change servers/databases when testing Deploy applications Exchange SQL-based workspaces with other developers Managed Connections lay the groundwork for multi-tenant application strategies because they support easily changing servers and databases on the fly

Defining Managed Connections The most typical, (and most simple) use of managed connections will be to store the Connection ID in a connections .ini file The full connection string and credential information is defined in DFConnID.ini (located in the Data folder, file name can be specified at runtime) [connection1] id=Chinook driver=MSSQLDRV connection=SERVER=.\SQLEXPRESS;DATABASE=Chinook trusted_connection=yes The Connection ID is then used in table .int files… DRIVER_NAME MSSQLDRV SERVER_NAME DFCONNID=Chinook DATABASE_NAME Album SCHEMA_NAME dbo

Managed Connections and Database Logins An application needs to login into a database server. Usually this occurs when the application is started is required – if login fails, the application should not be run is silent - it does not require user interaction uses credential information stored with the application’s configuration data (connections .ini file) The stored credential information must be secure is not a user login - this occurs before a user login

Storing Login Credentials Login credentials (trusted connection, user name, password) are stored in the connections .ini file. Those credentials may be: Trusted connections – this is the easiest login method and requires no special accommodation in the .ini file DSNs – with ODBC and servers that use DSNs. This requires no special accommodation in the .ini file User name / password – this is stored in the .ini file. Ideally the password should be encrypted. Storing encrypted passwords creates some challenges This must be supported both for your applications and in our tools The Application encryption method should be fully customizable and only known by the developer The Tool encryption method is controlled and only known by us How do you maintain encrypted passwords in the .ini file?

The Database Login Tool A tool is required to configure the credential information. That tool is a database login dialog that is only invoked when needed accepts input to perform the login stores the successful credentials uses the applications encryptions rules to store passwords can be customized by the developer can be embedded in your windows application or used standalone Our applications (Studio, etc.) uses a similar tool

The Connections .ini file A connection with user id / password information [connection1] id=Chinook driver=MSSQLDRV connection=SERVER=.\SQLEXPRESS;DATABASE=Chinook UID=AppUser PWD=8973753hskfjd DFPWD=sdfj876jdk

The Connections .ini file A connection with multiple connections [Connection1] Id=ID1 driver=MSSQLDRV connection=SERVER=.\SQLEXPRESS;DATABASE=Order trusted_connection=yes [Connection2] Id=RS1 connection=SERVER=MyRemoteServer;DATABASE=RemoteData UID=AppUser PWD=893753hskfgd

The Connections .ini file A connection with alternate connections [Connection1] Id=ID1 driver=MSSQLDRV connection=SERVER=.\SQLEXPRESS;DATABASE=Order trusted_connection=yes disabled=yes [Connection2] connection=SERVER=.\SQLEXPRESS;DATABASE=Order_Demo

Managed Connections in Your Applications Use cConnection.pkg Object oApplication is a cApplication Object oConnection is a cConnection Set pbLoginOnOpen to False End_Object Use LoginEncryption.pkg Use DatabaseLoginDialog.dg

Additional Connectivity Goodies More control over table edits. We support three table edit modes: Read-only Table .int file only (back end table definition never changes) Full edit Connection Redirection Allows the remapping of a managed connection to a different connection string Occurs dynamically at runtime Existing tables remain open Connections can remain open making switching very fast Assumes all tables have identical structures

Studio Support for SQL Features SQL Features should feel “natural” and fully integrated Managed Connections Data Types Primary Keys Indexes Table .int only editing We’ll look at all this during the demo

Compatibility Managed connections are supported with our MSSQL, DB2 and ODBC connectivity kits (starting with revision 6.2) The changes have been implemented while maintaining 100% backwards compatibility with… Existing SQL-based applications Embedded database applications Pervasive database applications No changes are required to keep doing whatever you have already in place Adding code to existing applications to use managed connections is easy

Connectivity Demo

Thank you