PDA

View Full Version : Backwards Compatibility - Drivers



starzen
24-Jan-2017, 08:19 AM
While DF allows installing and running multiple versions of the Studio and/or runtime side by side running multiple revisions of the connectivity kit against the same data folder is a nightmare

i am guessing this has not changed in 19.

Would be nice to either have

1) backwards compatibility of CCH files

or at least

2) a warning/error when cch files are incompatible

right now data is getting destroyed when running different revs of the conn kit which makes even updates of existing systems a problem

Bob Worsley
24-Jan-2017, 08:38 AM
Turn them off? There have been threads discussing that, some people claiming they've seen no performance difference...

Stephen W. Meeley
24-Jan-2017, 09:06 AM
Michael,

Unlike the embedded database, SQL connectivity has changed significantly over recent years and in my opinion I would never suggest that different generations of the drivers be used against the same data. It's more than just the mechanics of the .cch files - everything from supported datatypes to supported clients (and everything in between) has the potential to be different - and more so the further apart the drivers are (revision wise). IMHO, developers who deploy side-by-side revisions of their applications that are based in different host DF revisions but share common SQL data are best served by standardizing the level of driver they deploy (within reason). This takes them trough the process of making conscious decisions on what features and behaviors they rely on.

That said - I'm still interested in the specifics of what you are running into. What are the host DF revisions / driver revisions in play for you and are the cch differences between the two the main issue?

starzen
24-Jan-2017, 09:41 AM
Michael,

Unlike the embedded database, SQL connectivity has changed significantly over recent years and in my opinion I would never suggest that different generations of the drivers be used against the same data. It's more than just the mechanics of the .cch files - everything from supported datatypes to supported clients (and everything in between) has the potential to be different - and more so the further apart the drivers are (revision wise). IMHO, developers who deploy side-by-side revisions of their applications that are based in different host DF revisions but share common SQL data are best served by standardizing the level of driver they deploy (within reason). This takes them trough the process of making conscious decisions on what features and behaviors they rely on.

That said - I'm still interested in the specifics of what you are running into. What are the host DF revisions / driver revisions in play for you and are the cch differences between the two the main issue?

generally you wouldn't run different drivers of course but there are several scenarios were it happens

in development. converting an existing ws over to a new rev of df. you are using 2 versions of df for a while. copy the ws but keep using the same sql db

at runtime. We do automated deploys of changes including new runtime deploys. the applications are executed at the workstation and recognize a runtime install is needed and will then execute the update installing a new runtime. Not all users are going to be updated at the same time. because of the issues with the CCH files this does not work as the two conn kits will kill each other creating new cch files

And the worst part is that there is no protection. All it takes is one laptop that wasn't updated and runs against the db

Stephen W. Meeley
24-Jan-2017, 10:25 AM
Thanks for the additional information.

Both of those scenarios can widely be described as transition periods and might be served by turning off cch files during that period. If the development process is accessing live data I would keep cch on in the live environment and turn them off in the development environment (it should just ignore the presence of cch files completely and leave them alone).

The deployment scenario is more problematic but I'm not sure what is best done. If we were to add some sort of error checking (detecting a cch compatibility issue) what would be the appropriate action to take?

Evertjan Dondergoor
24-Jan-2017, 11:33 AM
You can use the same driver for the different versions of Dataflex. For a German customer we have a mix of DF-3, VDF16 and the big bulk now is VDF18.2. All those applications use the same data-folders, the same MSSQLDRV.int and the same driver. That by far is the best thing to do IMO.

If you feel it is needed - or unavoidable - to use different drivers, make sure you also use separate MSSQLDRV.INT files and specify different folders for your cache files. (I myself have never run it this way, but in theorie it should work.) Or just turn off cache files.

starzen
24-Jan-2017, 01:01 PM
You can use the same driver for the different versions of Dataflex. For a German customer we have a mix of DF-3, VDF16 and the big bulk now is VDF18.2. All those applications use the same data-folders, the same MSSQLDRV.int and the same driver. That by far is the best thing to do IMO.

If you feel it is needed - or unavoidable - to use different drivers, make sure you also use separate MSSQLDRV.INT files and specify different folders for your cache files. (I myself have never run it this way, but in theorie it should work.) Or just turn off cache files.

again if you read what i posted it is not about WANTING to use MULTIPLE drivers at the same time

it is about the fact that if different drivers are used against the same files by accident there is no protection and data integrity issues arise.

One way to make this work is to show an error and another one would be to simply ignore the CCH file if it was for a higher/lower rev.

Worst thing to do is to trash the data without warning

Peter van Mil
24-Jan-2017, 01:27 PM
Essentially I am doing the same. I am curious if the new version 6.2.x drivers can be used with DF 18.2 (and earlier). I didn't try it, but it can be interesting.

Garret Mott
24-Jan-2017, 01:33 PM
PMJI - but putting all workspaces on the same driver could mean that your environment does not match that of the client - which makes testing an issue unreliable at best - useless at worst.

Mike - thank you for pointing out this issue!

Evertjan Dondergoor
24-Jan-2017, 05:32 PM
again if you read what i posted it is not about WANTING to use MULTIPLE drivers at the same time

it is about the fact that if different drivers are used against the same files by accident there is no protection and data integrity issues arise.

One way to make this work is to show an error and another one would be to simply ignore the CCH file if it was for a higher/lower rev.

Worst thing to do is to trash the data without warning

No reason to get upset. Improvements at the driver are likely to happen. Meanwhile, if you think it is unavoidable to mix driver-versions, or they might get mixed 'by accident' as you put it, also use different cache-paths. It is just a suggestion. You do not have to follow up on it.

Clive Richmond
24-Jan-2017, 11:31 PM
Hi Michael,


1) backwards compatibility of CCH files


There are potentially a couple of attributes you could investigate that may help manage working with different CK driver revisions.


DF_DRIVER_CACHE_PATH (Cache_Path). This would allow you located the cache files into separate folders based on the CK driver revision being used. NB: Small caveat. This only worked from 5.1.0.74.
DF_DRIVER_REPORT_CACHE_ERRORS (Report_Cache_Errors). Help talks about 'read' errors so I am not sure if this would really help.
DF_DRIVER_USE_CACHE_EXPIRATION (Use_Cache_Expiration). On an application update you might be able to update the timestamps for the .INT files which should then force a regeneration of the .CCH file. However I can only see this working in conjunction with Cache_Path.



2) a warning/error when cch files are incompatible

An alternate approach would be to check the driver's revision against a minimum requirement and, if it doesn't match what you're expecting disable the cache (DF_DRIVER_USE_CACHE / Use_Cache), warn the user that an update is waiting to be applied.

Focus
25-Jan-2017, 02:39 AM
data is getting destroyed

what does the corrupted data look like?

is is some fields not saved ? Corrupt indexes ? Etc

ie what are the obvious tell tale signs it has happened ? Thanks

Martin Moleman
25-Jan-2017, 03:44 AM
The driver does check if the version that created the CCH is the same as its own version.
If not, the CCH is not used and a new one is created. So the driver never uses incorrect CCH version.

So, there is protection against multiple driver versions accessing the same data.
The worst thing that can happen is that both drivers keep generating new CCH's on open. That will slow down open speed, but it will not corrupt the data.

Marco
25-Jan-2017, 03:52 AM
I always have the driver.int in the ./data. Have the .int in a shared location, and have the cch in a shared but per ck version directory.
I would really like to see the cache path to be not only absolute but also support relative pathing (relative to the driver.int).

Samuel Pizarro
25-Jan-2017, 05:00 AM
One way to make this work is to show an error and another one would be to simply ignore the CCH file if it was for a higher/lower rev.

Worst thing to do is to trash the data without warning

I agree that thash the data without any warning is also the worst!
But for the approach instead of giving a critical error or just ignore the cch silently, I would raise an warning error saying the cch is being ignored due mismatch in format and ck version and contact your administrattor, and allow the application to run after the warning if the user wishes to proceed anyway!

Mike Cooper
25-Jan-2017, 07:02 AM
Hi Martin...

I think that this is what Michael is saying.... rather than having two versions which have been accidentally deployed constantly recreating the CCH files show some sort of warning message or even better don't allow an older driver automatically recreate CCH files. Speaking for myself, sometimes customers don't recognize that something isn't right and will just continue on. If they had a message pop up then at least we stand a chance of finding out about the mis-deployment.

Mike

Mike Cooper
25-Jan-2017, 07:03 AM
+1

starzen
25-Jan-2017, 11:47 AM
not corrupt as in garbage but data integrity issues depending on the difference in CCH files it will end up with all kinds of things. Kind of like running an app against a db that has fields missing or inserted but in reality you wouldnt know what will happen really.

And yes you know stuff is happening because of weird errors trying to save data and such.

Martin Moleman
25-Jan-2017, 11:54 AM
Michael says 'data is getting destroyed' when using different driver versions. I don't think that's the case.

You can get a performance problem when CCH files get rewritten on every open and adding a check for that is not a bad idea.
But I think a slower open speed is something different than 'trashing the data without warning'

Martin Moleman
26-Jan-2017, 03:24 AM
The driver currently is ignoring the CCH when there is a higher/lower rev.
It does it silently but we could add a warning.

If you really want you could add a warning yourself by querying the driver version (CKRevison function in cCLIHandler)

Martin Moleman
26-Jan-2017, 03:26 AM
I think you are misinterpreting how the caching mechanisme works.

The driver will never use information from a CCH file if the CCH file is created by a different driver version. If that were the case you could get situations like you describe, but that is not how it works. The version check is there to prevent just that.
The driver checks the version in the CCH with its own version and if there is a mismatch it will ignore all information from the CCH and read the table structure from the actual table.

Just having different driver versions will not cause any corruption like you describe.

Samuel Pizarro
26-Jan-2017, 08:37 AM
Hi Martin

Now I got confused. You said before the CCH are overwritten every time it does not match with current CK release.
and now, you are saying it ignores it.

So , I am totally lost. sorry

Regards

Garret Mott
26-Jan-2017, 11:37 AM
...So , I am totally lost. sorry

Regards

You're a programmer - isn't that normal? ;)

Evertjan Dondergoor
26-Jan-2017, 12:42 PM
Hi Martin

Now I got confused. You said before the CCH are overwritten every time it does not match with current CK release.
and now, you are saying it ignores it.

So , I am totally lost. sorry

Regards

It does both :-).

The driver sees it is a different version, so it ignores (the content) of the current CCH. Then it goes ahead and creates a new CCH with the 'correct' version.

Samuel Pizarro
26-Jan-2017, 12:50 PM
Ah . .

that's a different way of saying "Overwrites" it !

Thanks