Hi guys,

After re-installing all my dev tools due to a crash on one of my hard drive it is time to get back to my projects.

As I have expressed I am looking seriously into testing VistaDB database for a particular project where I believe an embedded database could fit the bill instead of using MS-SQL Express basically due to the large installation file and computer requirements for MS-SQL Express.

Reading about the VistaDB company Infinite Codex I found these two links which tells a lot about the company and the primary owner Jason Short:

http://infinitecodex.com/page/About-our-Company.aspx

http://infinitecodex.com/page/About-Jason-Short.aspx

Also thinking about the StrataFrame 2.0 I remember that Trent mentioned that they are looking to get rid of the StrataFrame.mdf database and use a more portable solution like XML files per project, so it will be easier to have DDT & BOM metadata stored with the project's files instead of the current SQL database, probably VistaDB.net could also fit the bill here since it is a single file, portable and can have any extension you want and mostly it is a database which could hold the DDT & BOM metatada in a single file per project and most important it uses the same SQL commands used now by those SF tools so porting those tools to use VistaDB should much more simple than using XML files and a good percentage of currently used code can be re-used for the VistaDB integration.  Does this make sense? Trent/Dustin

I will be finalizing some due installations today and probably tomorrow start the testing trial of VistaDB to see on first hand how compatible it will be with current code used in the StrataFlix sample application. 

Will keep you informed!!!!

Edhy Rijo

Hi Eddy,

I can't agree with you. VistaDB (wich I have downloaded for testing) is probably a good file-server database tool, for small (or tiny) amount of embedded data, as we manage in most of our projects.

But I would not rely on it to hold DDT and BOM. We need a safety brand, well known overworld (or no brand, and then a standard format as xml is ok).

Hi Michel,

On the contrary, VistaDB is a relational file database pretty much like MS-Access and my point is that it may be easier for the SF team to use it instead of a bunch of XML files to replace the strataframe.mdf database.  Taking into consideration portability of SF projects, if you are not connected to the SF database you will not be able to generate business objects or work with the DDT, so VistaDB may be a simple solution for SF and taking into consideration that based on their forums there are many developers already using VistaDB for a while.

Again lets not confuse things here, VistaDB is not a full replacement for MS-SQL/MySQL/ORACLE, etc.  it is just an alternative for projects with needs to use some sort of embedded file database and in the case of VistaDB it was created to be compatible with MS-SQL syntax which makes it easier to re-used code in current applications.

Edhy Rijo

Can't wait to see what you learn using VistaDB.

Thanks for the update.

Russ Brown (Using C#2010/SQL Server 2008)

I'm going to have to agree with Edhy and Michel on this one.



I think that VistaDb has potential for apps that we build that have small data needs and are used by individual users. While it might be fairly easy to deploy SQL Server Express, I can't imagine that it is easier than deploying an engine that is built into the app!



However, I would have to agree with Michel that using for the DDT/BOM is not ideal. The main reason I'd like to see it be something like XML is that I can do Diffs using source control tools. XML is just plain text. I really, really, really like that. Having come from an Access background, one of the most frustrating things about Access was that all of my development stuff (forms, code, macros) was stored in an unreadable format within the database. When Access would fubar my forms/code (as VS can occasionally do also), it was a major hassle to recover from. With VS (or any text based source), it is far easier. Most of the time I can simply edit the file to fix the problem.



My $.02...

Hi Greg,

I like the idea of having the XML in source code database, that would be a plus.

Edhy Rijo

Yep, having BOM / SF data entries in a more accessible, source-controllable format definately on the agenda for SF 2.0.  XML will likely be the solution here, for the reasons Greg and Michel outlined, but we'll examine all the possibilities when that time comes.