Garret Mott
9-Jun-2010, 06:33 PM
Hi -
This may ramble a bit, but I wanted to get some thoughts down while all this is fresh in my (alleged) mind. Some of this has probably been posted by others as well.
I've heard DAW say for quite some time that an SQL DB of some sort is the way to go for multi-user apps. While I certainly won't argue that, I do think that VDF needs to change quite a bit to really play well with SQL Server.
I realize most developers will be converting a DF DB to some flavor of SQL Server & that process is probably pretty smooth. I, however, managed to (as usual) do things the hard way & chose my first VDF/SQL project as one where the data existed outside of DF or VDF. In fact, I had to convert it from Access to SQL Server & that was a whole adventure in itself - on which I may post in the Connectivity forum at some point. Short of it: do not use the "SQL Server Migration Assistant for Access" tool that MS recommends! What a mess....
I should interject some info here. I am a (very rusty) MCDBA - so I do have a clue when it comes to MS SQL Server. In this instance I am working with MS SQl Express 2008. My past experience with MS SQL Server as a back end is with VB.
What it boils down to for me is that I don't get how VDF developers that cannot change the SQL DB can make it work with VDF. Being normal SQL data, what I have is full of Float, Real & Money fields. From what I've seen, VDF does not play nicely with them at all. After 12+ hours of converting them all to Numeric (x,y) - out of 4+ days of fighting with the conversion & figuring out that I had to convert fields - I have some views that will actually find records.
This was the main issue for me compatibility-wise - though I know I'll be dealing with date/datetime issues. I realize VDF now has date-time capabilities, but yet one can't utilize a datetime field in VDF. Text/memo fields? VDF cannot come close to what MS SQL Server can hold. Image fields? Nope (AFAIK).
Then there's how SQL data is accessed. Think how powerful using SQL statements instead of Constraints would be..... Yah, I know I've mentioned this before. ;)
I'm know there's more, but wanted to toss this out for consideration. I realize that backwards compatibility is important (& appreciated!) & that the current work on new grids is a huge step, but, along with more user interface objects (without relying on 3rd party controls - meaning 3rd party to us, the developers), utilizing all the capabilities of modern DB's needs (IMO) to be addressed.
Have at me!
This may ramble a bit, but I wanted to get some thoughts down while all this is fresh in my (alleged) mind. Some of this has probably been posted by others as well.
I've heard DAW say for quite some time that an SQL DB of some sort is the way to go for multi-user apps. While I certainly won't argue that, I do think that VDF needs to change quite a bit to really play well with SQL Server.
I realize most developers will be converting a DF DB to some flavor of SQL Server & that process is probably pretty smooth. I, however, managed to (as usual) do things the hard way & chose my first VDF/SQL project as one where the data existed outside of DF or VDF. In fact, I had to convert it from Access to SQL Server & that was a whole adventure in itself - on which I may post in the Connectivity forum at some point. Short of it: do not use the "SQL Server Migration Assistant for Access" tool that MS recommends! What a mess....
I should interject some info here. I am a (very rusty) MCDBA - so I do have a clue when it comes to MS SQL Server. In this instance I am working with MS SQl Express 2008. My past experience with MS SQL Server as a back end is with VB.
What it boils down to for me is that I don't get how VDF developers that cannot change the SQL DB can make it work with VDF. Being normal SQL data, what I have is full of Float, Real & Money fields. From what I've seen, VDF does not play nicely with them at all. After 12+ hours of converting them all to Numeric (x,y) - out of 4+ days of fighting with the conversion & figuring out that I had to convert fields - I have some views that will actually find records.
This was the main issue for me compatibility-wise - though I know I'll be dealing with date/datetime issues. I realize VDF now has date-time capabilities, but yet one can't utilize a datetime field in VDF. Text/memo fields? VDF cannot come close to what MS SQL Server can hold. Image fields? Nope (AFAIK).
Then there's how SQL data is accessed. Think how powerful using SQL statements instead of Constraints would be..... Yah, I know I've mentioned this before. ;)
I'm know there's more, but wanted to toss this out for consideration. I realize that backwards compatibility is important (& appreciated!) & that the current work on new grids is a huge step, but, along with more user interface objects (without relying on 3rd party controls - meaning 3rd party to us, the developers), utilizing all the capabilities of modern DB's needs (IMO) to be addressed.
Have at me!