Dextar® Technical White Paper

Device integration to MSFoxPro®

Document Creation Date:May 2006

Copyright© 2006 Dextar Ltd (New Zealand).

Contents

Contents

Introduction

Prerequisites

Before you begin

Connecting to your Database file

Connect to your MSAccess database file from Dextar

Mobile Interface Configuration

Revising the Mobile Interface to suit your new database

Mobile Data Deployment

Exposing data to the Mobile Devices for lookup

Mobile Data Collection

Collecting data from the Mobile Users

Introduction

So you have an enterprise database and you want to mobilize it?

This document outlines the procedure for integrating the Dextar Mobile Business Assistant tool with any FoxPro® database.

In the demo version of the product, you will see the Dextar rapid deployment tool in action, based on a standard MSAccess database (DextarDataLink.mdb)

Dextar’s function is to automate all of the deployment and data synchronisation processes between the database and (multiple) mobile devices.

It provides an easily customisable user interface with point & click ease – no programming required.

The fact is, you can map Dextar to any database and it will carry out the same functions. Of course every database has a different structure (schema) but as soon as you connect to a new database, Dextar ‘morphs’ itself to the new schema. The Dextar Simulator immediately allows you to create meaningful mobile deployment options from the new schema.

We made MSAccess our initial database of choice, because it’s so versatile. You can easily use MSAccess own data linking tools to create ODBC or SQL connections to virtually any other data source – even combining multiple databases on remote servers – or MS Excel®, Crystal Reports® and many other useful tools.

Of course MSAccess is not Dextar’s only option. We can provide similar links to FoxPro, SQL Server and Plug-Ins to a variety of other industry specific applications. We even provide an Open Source toolkit for Visual Basic development of custom integration Plug-Ins.Simply o join our developer partner program.

Prerequisites

Before you begin

Dextar / You must have the fully registered version of the Dextar software installed on your PC or server (some data communication features are disabled in the demo version).
FoxPro / It is recommended that you should have your own installed database editing tools if you wish to carry out structural changes to your Foxpro database.

Connecting to your Database file

Connect to your Foxpro database file from Dextar

Browse to the filename. / Connecting to your database is surprisingly simple:
  1. Startup the Dextar application.
  2. From the initial screen click the Database Browse button:

(and select MS FoxPro® database format)
  1. Find a database name on your network and double-click to select it.

(Select any .dbf file; Dextar will automatically reference all data files from within that folder)

Mobile Interface Configuration

Revising the Mobile Interface to suit your new database

Simulator / On the Simulator screen , you can now see all the .dbf tablenames within that folder listed for selection as Main Menu options.
Then as you select each tablename and navigate down to its submenu page (displayed on right half of the screen) you will note that you can now see all the FoxPro column names in that table listed for selection as ‘questions’.
Note: if you can’t see these, check the Data Import Settings checkbox to display these Fields.
You can see that we have simply exposed your FoxPro table / field structure to the user in an intuitive Menu / Questions paradigm.
Having thus selected which tables / fields they wish to deploy to the mobile device user(s) you may then use the Simulator to rename the (titles of the) fields as necessary to simplify the end user experience.

Mobile Data Deployment

Exposing data to the Mobile Devices for lookup

Data Engine / Having used the Simulator to select Fields, Dextar now knows what data is required to be sent to each mobile device.
Dextar’s background data synchronisation engine now takes over this task, automatically extracting data from the .dbf files polling at regular intervals (of 5 seconds) and compiles these into encrypted and compressed data files for transmission to each device in a fault-tolerant process suitable for a non-persistent connection.

Mobile Data Collection

Collecting data from the Mobile Users

Simulator / If you define any ‘question’ in the Dextar Simulator as an Input type (such as Text or Number input) then the mobile user will have the ability to make a change or addition to that ‘question’ and click SUBMIT to post that change data back to the server.

Dextar’s data synchronisation engine then automatically collects and posts those changes back into your FoxPro database using the following rules:
  1. If any ‘question’ (ie. Fieldname) on the page maps to the 1st, 2nd or 3rd column (respectively) of the FoxPro.dbf file from which that page is mapped, then Dextar will attempt to match the entry to an existing record matching that key value. If found, it will update all data changes from that page, to that record.
  2. If a matching column name was found, but not a matching key entry, Dextar will append the incoming record to the table.
  3. If none of the above conditions exist but the table contains an Autonumber Primary Key field, then Dextar will attempt to append the record on that basis.
  4. If none of the above conditions are successful, Dextar will output the requested change data record as a tab delimited line entry appended to RejectedTransactions.txt in Dextar’s application folder.
Posting Transactions to an alternate location:
It is possible that having used an existing table to define the ‘question’ parameters for the end user, you (the system integration designer) may not wish their data collection to be posted directly back into that table. eg. The transactional data may require additional rules applied before posting.
In this case you may setup a ‘clearing’ .dbf file to hold this transitional data. Then in the Dextar Simulator, you should reference this alternate tablename in the ‘Alternate Transaction Posting Table’ dialog provided for that page.
PRIVATE AND CONFIDENTIAL
1