1. Connectivity in DataFlex 19.0
John Tuohy

2. Improved Indexing Support

3. 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

4. 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

5. 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

6. 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

7. Convert, Connect, Refresh and Reconnect

8. 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

9. Managed Connections

10. 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

11. 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.)

12. 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”

13. 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

14. 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

15. 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

16. 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?

17. 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

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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. Connectivity Demo

26. Thank you