I have a VFP database table set up as a Business Object. In VFP. If I append a record in VFP ,I get "  /  /  " for a date field   (Date field which is Balnk)  and gen for a Genral Field (seems to be an empty gen field).

I am trying to do the same in the Buisness Object. How do I get a Blank Date into a date field and gen into a General Field. Currently, If I allow nulls, it seems to put a date of 01/01/1800 intot he date field.

Also, when I drop the Field onto the form, there is no automatic formatting based on the field size in the table (e.g. say Numeric field with 10 digits and 4 decimals is displayed as just decimals). Is there any automatic way to take the formatting from the table i.e. in example it would have a mask of 999999999.9999

Well, let me prepare you a little bit here...you can definiltey deal with all of this, but VFP is not like most other databases...and since you are using the VFPOLEDB provider, there are even more limitations.  We spent days working through problems like this.  FoxPro has become somewhat of a "bad" word around here...it took us a while to "see the light" so to speak, but once we finally got it we realized that we had been living in a dark and dreary world (VFP).  Some of these pains will persist even while in .NET if you are still trying to talk to VFP tables.  Dates are one of these frustrations.  The only way to clear out the date is to manually call an UPDATE on the field:

The above code may not be exactly right, but it is going to be close.  I am going from memory here, but should allow you to "clear" out a date field.  We took the 1/1/1800 approach where we could as an empty date, but to truly clear the date in VFP terms, the above command will do that for you.  You can always place this logic in a BaseBO that all of your BOs inherit so that you don't have to write this over and over again...for example, you may want to have a BaseBO, then a VFPBaseBO that inherits from the BaseBO.  Then any BO that will talk to a VFP table would inherit from the VFPBaseBO (where you place the additional logic to take care of Date fields) whereas all other BOs would inherit from your BaseBO (which inherits MicroFour.StrataFrame.Business.BusinessLayer).

In regards to the auto-formatting, then answer at the moment is, "no."  This is something that we may consider in a future update, but for now this just has to be done manually....which to be honest hasn't actually gotten in my way.  I never used it in VFP so I don't miss it...however, this is a request that has come up from time to time and is on our list of future enhancements.

Where in the BO would I put the Code to run the update command 

You could go about this a number of different ways.  The simplest would probably be to handle the AfterSave event and then update the dates after the BO and DAL have already done their work.  But you could go down a lot of roads here.  If this isn't what you want then let me know and I can throw out some more complicated approaches, but if this meets your needs then this would be the most simple approach.

Hi Trent.

At thi stage. I am experimenting, and am using VFP tables because I am familiar with them and am getting up to speed on Strataframe by emulating an exiting VFP app.

As a metter of interest, is MYSQL supported (it deoe not seem to be there as a default) .

We do not have a provider for MySQL and in fact you can find another post on this topic from just the other day.  There is very little demand for MySQL and if you have this need you can definitely create your own DAL just as we did for VFP, SQL and others.  However, we actually do have this on our list.  But since there is little to no demand for MySQL, there are other priorities that preceed this DAL.  In regards to a time frame, I am not entirely certain.  We intend to make a number of other framework changes such as BO Mapper enhancements, etc. before this will be considered as "in the pipe."

I am not sure your reason to consider MySQL over SQL Server, but SQL Server Express alone is more than enough database for most applications and it is a free solution with the option of easily upgrading to a full version if the need exists...without having to change your application, etc.  I was just curious on this point....usually when people use MySQL they are either using a hosting site that hates Microsoft and refuses to support SQL Server or the developers themselves have something against SQL Server...so I was just curious as to why you are choosing MySQL over SQL Server.

HI Trent.

The MySql query was of a general nature. We have quite a number of clients on existing  APPS where the combined Database Size (In VFP adding all Tables) comes to more than 2 Gigs, and I understand Sql Express has a limit of 2GIGS in any one Database. This would mean that clients would need to be upgraded to Sql Server (Full Blown Version) and there may be 'sudden'' unexpected cost implications..... Our typical users would be 5 to 10 users with a significant no. of clients in the 15-30 bracket.

Having siad that, I dont have up todate costs on Typical Sql Server costs for say 15 users .

Also, from browing some forums, it is suggested that MYSQL is faster than Sql Server, although I have no definite concrete evidence to back this up.

Actually this is not right.  The limitations for SQL Server Express are:

4GB per database limit
No more than 1 GB of memory will be used
Only 1 processor will be used

Actually this is not accurate either.  This was actually true in certain conditions when dealing with pre SQL Server 2000 environments, but this was no longer true with SQL Server 2000...then with SQL Server 2005 and 2008 I know for a fact this is not true.  Microsoft used to get beat up and lose market share pre SQL Server 2005 to Oracle and other databases in regards to performance and speed, especially with extremely large databases.  Microsoft made it their personal mission to prevent this...and they came through in a major way.  There are still some grumblings from those people who just love to hate Microsoft...but this is no longer true.  SQL Server 2005 and 2008 are now starting to set the bar instead of trying to catch up.  MySQL gained marketshare from the web based applications early on because it wasn't Access and it was free...at least for a while and up to a certain point. 

Like I said, we will probably create a MySQL DAL at some point, but if you have a choice, I would definitley not choose MySQL over SQL Server...this could really come back and haunt you down the road.

Hi Gerard,

The Sql Express size limit is 4 gig's, and you could split your application across multiple databases if it made sense to do so thus increasing that limit.

The other thing is foxpro data size might not nessesarily equal SQL data size, If you add up all the data in my fox table's they are 3.57 gigs however the same data in SQL is 2.2 gigs, I cleaned up the database design as well as made changes to datatypes etc. 

As far as the speed thing not sure about that but it is possible as Sql Express does limit the memory usage to 1 gig and one CPU so i guess that could have an effect with lots of users but i doubt it would affect 15 users at all

Just my 2 cents as I have already went down this road and found nothing bad about SQL express for me..

Hi Gerard,

Just to echo Trent and Paul's comments, I'd definately look into SQL Express as an alternative to MySQL if possible. MySQL is a fine database, but in my experience, SQL Express provides a great (also free) alternative that will give you much more room for growth and a tighter integration with .NET. I haven't had much experience with MySQL recently, so many of my old gripes may have bene resolved, but SQL Express will certainly give you a better "ceiling" by way of the enterprise edition both on scaling and on the coding end as well (i.e. T-SQL support.) 

Obviously, the main caveat to going with SQL Express is if the memory or cpu limitations Trent mentioned are going to really hamper you (i.e. you are planning on using it in a demanding or high-volume environment.) For 15 users, however, I highly doubt you'll notice the limitations at all. 

The file size issue isn't as big of a deal unless you are planning on storing media files within the database. As Paul mentioned, you can always split your database into multiple file groups to handle a larger number of records (which, excluding media files, would need to be pretty large to begin with to exceed 4 GB.)