Bozteck takes pride in making complicated tasks simple.  That has been the philosophy behind VNCScan for the past 13 years.  We’re making some really COOL changes to the product to do just that.

Historical Overview

When the first versions of our VNC Manager were released way back in 1999, the data was stored in a Microsoft Access database.  Despite the popular (and often justified) opinion of Microsoft’s Access database, there are some applications that use data “just right” for that platform and VNCScan was one of them.

After frustrations with requiring multiple runtimes for Access, the decision was made to move the data to an XML format.  A lot of code was written to manage that process smoothly on the thousands of existing VNCScan installs deployed all over the globe.  The XML format has been working pretty well over the past 10 years but there are some pretty serious issues that the time has come to address.

Issues with XML Databases

The largest sacrifice of moving to XML was the ability to share one set of data with many administrators.  When the back end was database driven, multiple computers could pull from the same data at the same time with very good performance and reliability.  After moving to flat XML files, doing so often led to groups disappearing and data files that became corrupted so badly that it prevented the program from starting up.  We had to remove any support for sharing data with XML. because of this.

For example, if John and Mike both point their VNCScan consoles at the same data location, they will constantly be stepping on each others changes.  An XML file must be read into memory, modified, then placed back onto the disk as a complete file (overwriting whatever is there).

If John reads the data into his console, then Mike makes a change to the group, and then John makes a different change to HIS copy of the group, Johns change will wipe out Mikes change even if they change different properties of the group.  If they both try to write their changes simultaneously, they end up with a corrupted XML file.

The Great Database Debate

A while back, I made a blog post asking opinions of using an Access back end verses using a Microsoft SQL Server back end.  I received a lot of emails with great responses from so many of you!

On one hand, the Access database format needs to be compacted and repaired from time to time to get rid of orphaned data and “white space” in the database.  It also does not do well with a lot of threads hitting it at the same time.

On the other hand, Access is a very portable database format that requires no runtime (any more) to use in your program and holds up well with the type of data accesses that VNCScan performs.  I’ve also taken performance heavily into consideration with each line of code that I have written to mitigate any “over use” of the database.

If we were to use a SQL database, we would need to deploy the Microsoft SQL runtimes (MSDE) or require that every customer has a SQL server on premises.  For the style of data that VNCScan employs, both of those options seemed like overkills at this point.

The Future

The initial database version of VNCScan will be backed by a Microsoft Access database.  The code was written in a way that will make it VERY easy to port it to a SQL database in the near future.  While we have tested VNCScan extensively on the Access database, we will be watching “wide eyed” for any indication that the platform isn’t good enough.

I believe that by June, we will have a version that will have a choice between Access and SQL. We’re only releasing the first version as Access based to cure the ills that plague the XML.  Even with its shortcomings, Access databases are a hundred times better than XML.

The Beta

We are in the final stages of “dog fooding” the database version.  That means that we’re using it internally so that we feel any hardships before the beta testers do.

Within the next day or so, you will see a bog post with instructions and a link to try the beta.  I strongly suggest that you back up your <My Documents>\VNCScan folder before installing the beta.

Twitter This

UserName: Password:

The recent changes in VNCScan has revealed some confusion regarding the data files, their locations, and what they all do.  For a historical primer, you may want to start with this blog post.

Key Data Folders

The data files are stored in three key folders;

• Data – Stores all of your program settings, group settings, and computer settings.
• Jobs – Stores all of your remote scripts.  Each script job has a subfolder named after that job.  That subfolder contains all of the files required to push and execute that job on a remote computer.
• Profiles – Stores all of your VNC deployment profiles.  Each deployment profile gets a subfolder named after it.

The Root

All three of these key folders must be stored with in the same Root folder.  By default, the Root folder is “My Documents\VNCScan”.

The first time that VNCScan runs, it checks the registry key “HKEY_CURRENT_USER\Software\VNCScan\SettingsDataPath” for the path to the root location.

If that registry key holds no data or if the path doesn’t exist, it will create the required folders at the default location and start fresh with new data.

The Key Files

Both of the following files must reside in the Data folder:

· Settings.xml – This file holds all of the initial settings for the console. This file stores anything that is global to the application.

· Groups.xml – This holds all of your group names along with their settings. You will find XML files in the same folder named after the group names, also. These files hold the computers and their settings.

Twitter This

UserName: Password:

We’ve posted the latest release of Bozteck VNCScan Enterprise Network Manager (VENM) to our downloads page today!

If you saw that there was a version 2010.2.3 and downloaded it before we could correct the error, you probably downloaded a (less than stable) beta version instead of this release.  Please re-download the update to be sure that you’re on the stable code base.

We’ve done some more work to make moving your data files around much easier.  You can modify the root location (the folder that contains the data, profiles, and jobs folders) in the main program preferences in the “Support Files” section.

If you’re moving the data to somewhere on the same volume, you can simply hit the “Change” button and browse to a folder where you want them to be.  When prompted, let the program move the files for you into that location.

If you’re moving to a network location or another volume, manually create that destination folder and copy the data, profiles, and jobs folders into that new destination folder.  After this is completed, follow the steps above and answer “No” when asked if the program should move the files for you.

Twitter This

UserName: Password: