Working with Visual DataFlex 14.1

A new addition to Visual DataFlex 14.1  studio is the ability to do data modeling without leaving the studio. The erstwhile DBBuilder still works but is being designated as a tool to maintain the embedded DataFlex database. 

The VDF 14.1 studio was designed to work with minimal changes in the various drivers available in the market from Mertech and DAW. In order to get the information the studio needs  from the driver, a driver specific XML file was introduced which contains attributes supported by the underlying driver ( look in your VDF 14.1bin directory for these files).

Mertech's V9 and v10 drivers both work with VDF 14.1 runtime.  However, since most of the changes in VDF 14.1 are in the studio, meaning the new features are geared towards the developer, we recommend that you use v10 drivers for working with VDF 14.1 studio.  

If you do use v9 drivers with VDF 14.1 studio, you will encounter a couple of issues:  1)  you will encounter a crash in the studio when the Mertech login dialog  pops up when you open the table. This is due to some resource contention at the runtime level. This issue was fixed in v10 working in conjunction with Data Access  2) Some new attributes were added to v10 which are present in the driver XML file shipped with VDF 14.1. These attributes are absent in v9 drivers and you will get errors about missing attributes. 

So our recommendation is that if you are using VDF 14.1 studio for designing your apps, use v10 drivers. However, you can continue to deploy with both v9 and v10 drivers with VDF 14.1 runtimes.  The new changes in v10 though will give you better performance and new features.

Refreshing Table Structure

To solve this issue, Mertech decided to completely get rid of .TD files so that on every open, we get a fresh structure information from the server and improved the code to open the files just as fast the first time and much faster if the files are closed and opened again. We do this by caching the structures in memory. 

VDF 14.1 studio refreshes the table structure by first  deleting the driver structure cache files (.TD or .CCH in the case of DAW CKs) and then opening and closing the files and generating the .FD file on the fly. This forces drivers using the cache  files to re-read the table structure information from the server.  We feel a better approach is to do this through the API and let the driver handle it (but that is a different story). 

In the case of v10 drivers, if the change is made to the backend and you refresh the table structure, the change will not be read back into the studio because we do not have the .TD files anymore and opening and closing will not release the in cache memory. If the studio had done this through an API call, let the driver handle it, then this would not have been a problem because the driver knows how to refresh its structure information (we have added a new command for that).  Because v10 always reads the data from the backend the first time a file is opened, you will always get the most up to date table definition. However, if someone makes the change to the table while you had the file open, then you will have to get out of the studio and then reopen it.

This is a temporary issue, has limited scope so we will be fixing this  in the next inline revision of v10 drivers.