We have been hit quite a bit lately with tickets and requests from users around third party tools. Yes, third party tools can simplify your development efforts in some cases. But are you really making your support requirements more complex?
Debugging third party tools
We simply do not have the resources to help users debug issues with third party tools. In many cases the questions are usually very specific around this vendors tools and how do the features map up to traditional ADO.NET use cases. We simply have no idea how the vendor intended for you to perform certain actions.
Did the vendor encapsulate you from VistaDB? If you are not working with ADO.NET constructs we will have no idea how to help. Either the vendor did or did not encapsulate you from the database.
Encapsulation from the database?
A fundamental property of encapsulation is that it hides the underlying complexity from the user. The user should only have to know what the component does, or how it achieves the underlying work. Encapsulation should also protect the user by not allowing them to get the underlying object into an inconsistent state.
Another benefit of encapsulation is that in good implementation it should reduce the complexity of the system, and limit interdependencies between software components.
Relational Databases are complex. The ADO.NET data model is complex. When you start looking at the knowledge required to navigate between SQL, relation data, and ADO.NET it can be quite formidable.
Encapsulation can also mean data hiding
In C++ classes I used to teach that encapsulation also meant data hiding (one of the tenants of good object oriented design).
How can you debug or diagnose a problem in their tool? Any tool that is wrapping VistaDB to hide the complexities of databases from your code is now responsible for that database management. Either the vendor hides you from the complexities or they don’t – there is not much room for a middle ground here.
If you still have to drop to ADO.NET code to do things like build relationships or do reporting then did the tool really save you that much?
What should you do?
Contact the vendor and ask for their support. If the vendor has an actual issue with VistaDB not performing an expected action then the vendor should contact us for support. You are after all supposed to be encapsulated from having to think at the database layer.
Many times we find that the vendor has a bug in their application, or in product documentation. We cannot help everyone track down issues in every third party tool.
Tools for VistaDB Express?
Vendors who sell commercial products may NOT use VistaDB for their development. It is a clear violation of our EULA. All commercial vendors must have a full license in order to build tools that expose any functionality for VistaDB.
There have been complaints to us from a few vendors who were only building when a new VistaDB Express build was released because they did not have a valid VistaDB license. If you sell a product that uses VistaDB you must have a commercial license, period.
Third Party Tickets
We will not accept tickets for third party tools without reproducible error cases for VistaDB runtimes. Issues that are generic in nature such as “SQL runs on SQL Server” or performance related issues will not be supported.
If the tool simply does not return correct results, or is somehow performing incorrectly we will not modify our database engine to fix a broken third party tool. This has been an issue before with tools that relied on incorrect behavior or undocumented features.
If the tool is encapsulating you from the database, it had better know how to generate compliant SQL for VistaDB. In many cases poorly written SQL queries will perform incredibly bad on VistaDB. If you have no ability to modify them we cannot help.
Zero modification of runtime or databases
The only way tools should be interfacing with VistaDB is through our runtime. No third party tool may modify the VistaDB database files directly. Any vendor who tells you they manipulate the database directly is lying. They have to run through the engine or they are putting your application at risk. We work hard to ensure that interfaces remain constant in expected behavior, but the underlying file format can and will change over time.
Is VistaDB really supported and tested?
Ask your vendor if they support VistaDB in their product. If their answer is “we load .Net Provider Factories” then that means they have probably not tested it with VistaDB. Do not accept a blanket – we load others so it should work answer.
Are you going to trust that to your customers? Most of the time these vendors when pressed later about an actual bug will usually leave the user without a fix because “it works with the [some other] database engine”. Don’t accept that answer.
If you are purchasing a product because you have been told it supports VistaDB make sure the vendor will actually support their product. If they give you a blanket answer about running through a test suite, think long and hard about where you will be if an error occurs in your application.
If you have no ability to fix the tool you will be in a very bad place with your customers, through no fault of VistaDB. Even though we have spent many, many hours trying to help customers get resolution from third party tools we cannot continue to do so.
We support VistaDB
We support VistaDB, we test constantly for compatibility with ADO.NET and all known published standards. When we find issues we strive to fix them as quickly as we can and to notify the entire community about those fixes.
Make sure the third party tool you choose is really going to save you time and energy. I hate to see frustrated customers dealing with situations where we can’t help them either.
Subscribe