All licenses are 10% off for the duration of the sale.  If you contact us after the sale, sorry, you missed it.

You want to the source code added on to your Small Business or Corporate account we are offering it for 50% off these same two days.  Open a ticket with your information request and we will take care of you.

 Visit the online pricing page for more information.

Continue Reading...

I have been working on this blog post for around six months.  I keep writing and shelving it.  Today I read a blog post from the DexExpress CTO that got me back to wanting to publish this post.

Early Adopters?

To put what Julian said in different terms; Do you want all the Early Adopters for your product?   There are pro and con arguments to having the early adopters when it comes to technology. 

While they tend to be some of the most passionate people out there, and they are usually eager to play with a technology but have little to no loyalty to that technology.  By the time you have stabilized your product cycle they will be long gone on to the next technology buzzword to play with it.

They also tend to have the most harsh reviews of the early technology.  They will bash it as not complete, or not like product x, etc.  But by the time you have addressed their issues they will never come back to update those huge blog rants they did against you in the early days.  Their social media contracts tend to be very one sided – whatever is in it for them today.  After all anyone on the Internet can post a blog slamming a product or technology as inferior.  You don’t need credentials or facts to back you up.  Just post it – people will believe it.  And if the company actually listens to you and implements your suggestions you can always shrug them off as not being “agile” enough for you (IE, they didn’t give you that build the same day you asked for it).

Buzz word and gone

Microsoft is great at playing into this early adopter hype.  They print magazines with all their buzz word laden technologies sometimes years before you or I will be able to put it into production.  And by the time you do get around to wanting to use it in production they have often already abandoned it for another, newer, faster, more buzz word laden system.

Look at Windows Workflow (WF).  Anyone who early adopted it is probably kicking themselves now.  Microsoft has basically punched reset on the entire design.  I really looked at implementing VistaDB serializers for WF.

They can’t remove it from the framework!

And to all the people who use the argument that they can’t remove it from the framework - that is just silly.  LINQ 2 SQL (L2S) is a good example of this.  Microsoft printed tons of material about it, but you weren’t supposed to take it seriously.  It was just until the more serious Entity Framework came along, didn’t you know? 

Well, from the number of articles, books, etc I don’t think anyone understood that argument.  So if you did buy into that technology what about .Net 4?  Well, Microsoft has said that L2S will exist in some capacity, but what does that mean?  To me it means it means you had better be embracing .Net 3.5 SP1 for a very long time. 

If your favorite buzzword technology was implemented in a SP how stable is that to actually deploy?  I know lots of shops that still refuse to deploy .NET 3.5 SP1 because of the problems they had with the “Service Pack” changing how things worked for their applications.

Continue Reading...

This is an update to the VistaDB 3.6 preview builds as we continue to push forward towards release. 

The Data Builder now has tabs support on the SQL input windows (yea!).  And some minor display changes.

There are a lot of API changes in this build, but I think we are finished for changes to this version.  The majority of the API changes were to complete the ripping out of the V-Index system that was non standard.  It has been deprecated since VistaDB 3.2 or 3.3, and we are finally removing it.

We also changed the event handler and object class name for monitoring PRINT messages from your SQL Code.  The help has a new topic on how to monitor SQL PRINT messages in your code.  We changed the class to match the naming from SQL Server.

This installer will only be able to uninstall and upgrade 3.6 installs.  If you are running any 3.6 prerelease you can just run this setup.  If you are running any previous 3.x build you must uninstall it first before installing this build.

Continue Reading...

As was discussed in the previous blog post about VistaDB 3.6 we are now ready to being Alpha testing.

Why Alpha? 

This is a new installer.  There could be problems with the install process and I want to work them out quickly.  I expect to have a few releases of 3.6 during the Alpha stage before we are ready for Beta.

There are a lot of internal engine changes.  We have 3 known bugs we are still working right now, but we want to get others started testing as well to make sure we didn’t break anything with existing apps. 

What is in this release?

New Tarma based installer.  I am planning to do another post about our switch to Tarma, but things have gone very smooth so far.  I am quite pleased with the performance and options of the installer.  Their support has also been fantastic and very helpful.

The sample databases are now copied to the shared public folder of users.  Shared Documents\VistaDB\Databases and Scripts are now included.  This is to make it easier to use the demos on a UAC enabled machine without requiring Admin rights.  The blank database template (blank.vdb3) is also copied there now.  When you right click on a folder and add a new database that blank.vdb3 is the file copied.  This allows you to setup defaults you always use (page size, locale, etc) and get them when a new database is built.

Data Migration Wizard is NOT included yet because we are making changes to the interface and functions.  The older DMW will be made available as a separate download for users who need VistaDB 2 migration with instructions on how to use it.

Samples are also not included other than the NUnit test project.  Samples are being restructured and will be ready before the final release of 3.6.

Continue Reading...

It can very frustrating trying to help someone who is asking for help, but not giving you what you need to help them.  I wanted to put together this post as a sort of FAQ on how can we help you with things like queries and schema problems.  If we can’t get certain information we often can’t offer more than general guidelines – and those may or may not apply to your problem.

Query Performance

In general we do not provide support on query performance.  There are just too many ways to write the same query, some are fast, some are slow.  There is often no way to know short of trying them.  In most cases either query is good enough and people just move on.  But what if your query needs a certain response time? 

If you are simply taking a query from Access builder and it is too slow, that is not good enough. Did you try ANYTHING else?  Check your indexes?  Anything?

Engine one off code and customization

Microsoft SQL engines (Access, SQL Server, and SQL CE to a lesser extent) will rewrite poorly written queries for you.  They sometimes build indexes, temp indexes, lookup tables, cross reference lookup temp systems, all sorts of things under the hood that you may not know about. 

So why don’t we do all that?  Microsoft spent $1 BILLION on the company that provided that technology.  Yes, that is with a B – wow.  And that is part of the reason SQL Server is so large. 

It has a lot of code paths that are special cased code for one off scenarios.  We don’t do that because we want to stay small and lightweight, and because each of those cases you add also have to be documented, tested, and maintained.  Each of those add a lot to our workload.  If you have 10 special cases to 10 functions you now have 100 combinations to test.  Start chaining that out through all the clauses and you end up with huge complexity for test purposes.

Special Cases?

Does that mean we will never special case code?  No. We will do it, but only with really good evidence that it is going to impact a lot of use cases.  How do we build those use cases?  Use cases is where you can really help us.  We have a lot of usage scenarios based upon standard ADO.NET patterns and practices.  Then we have quite a few from our own applications we built that broke those patterns.  Add to that problem reports from users, and you start to get a pretty good comprehensive coverage of SQL patterns.

Continue Reading...