An error like this can be easily generated by the end user.

I know I can create a lot of broken rules to validate the field Length, but I strongly believe that this should be handle by the Business Object Mapper since it has all the information needed to add this kind of validation to the BO designer file.

Trent,

That is exactly my point, the BOM metadata has the field length information then enforcing this kind of rule should be more practical if done via the BOM in one single step instead of me going through all fields in all my textboxes setting the MaxLength manually and then keep remembering to do it all the time.

This is the kind of rule which is a MUST because if I don't do anything to enforce it, then the database will throw and exception which is not good for the end user.

My request is to add this kind of functionality in the BOM to either enforce this via the textbox MaxLength or to automatically generate a broken rule like this:

I feel like we keep going around in circles here.  I have already told you, in more than one post, that we will consider adding some of this functionality down the road.  Developers create massive applicatons, everyday, including ourselves, without letting this slow us down.  It is a very simple property to set...this is not a "show-stopping" request.  You are coming from a data-driven environment...VFP.  We too came from VFP and have implemented logic into the framework with many of the good ideas that they had...the request you are making is coming from a data-dictionary environment which using thi same logic would be suicide in a large application in a disconnected data environment.

We WILL at some point add additional functionality that will bring in field lengths.  Though this should never have to be checked at the BO level...though you could do it this way, it is really pointless as you can set the MaxLength on a textbox to prevent this from ever getting to this point instead of the end-user seeing another error or warning.  So this logic is not as simple as you keep bringing up...because this 1.) needs to be optional 2.) impemented at the control level which means any control that supports text entry will need to support this logic, thus making 3rd party controls more complex. 3.) Needs to provide support for all environments versus just our controls, etc. 4.) This will require support for al database types, not just SQL Server and so it will entail checking for VarChar, NVarChar, and support for SQL Server, Oracle, DB2, VFP, Access, OLEDB, etc. 

When developing a framework and trying to appeal to the masses, it is best to make the change so that it will be respected in the broad spectrum.

Finally, if this is such a huge piece of your application, you could implement this logic in less than an hour.  If you want to take the BO approach, then inherit the BusinessLayer and create your own BoBase (which is a good idea anyway) and then add this logic to check for field lengths for your specific data type....though I would still recommend doing this at the control level.

I hope this helps you understand that I have heard you on all of your other posts and help you to understand that you can add this logic yourself very easily since it will not need to support all data types, etc.  We try to listen to all of our customers and meet their needs.  Especially in areas where there is a high-demand request...which though this is not in high-demand, we do see that there could be some things that help speed development up in the long-term.  Thanks for your input and understanding.

Trent,

As I said before in this forum, I am new to .NET and do appreciate any kind of input anybody here can do to help me out.

Please don't get my postings in the wrong way, if I gave you the impression of going in circle in this topic, that was not my intention.

I am in the process of converting VFP projects to VB.NET with SF, while doing this, I am learning the .NET way of doing some things and along this the SF approach to those situations, so my posts are in regard to let you guys know of things I believe may enhance SF in the future, based on my experience working with VFP frameworks, of course that does not necesarily means that I want that feature today, or that it is a valid doable feature.

Since you made the suggestion, I am already using the MaxLength property .  So far, nothing is a show stopper for me the easy way would be to keep building solutions for my customers with VFP and here I am in the .NET world using the framework I believe is closest to what I am used to, and believe me it took me a while to review other framework vendor and decided to stay and invest in SF, and one of the major reason for my decision is the kind of support provided by you and the other SF team members.

Anyway, thanks for the points!!!

I understand exactly what you are going through at the moment, as do many other developers out here on this forum.  It took us a while to "break out of our shell" so to speak and finally smell the roses   Many of the things that you are fighting is simply just trying to come from an environment in which you were comfortable and then try to apply those same techniques towards .NET.  Obviously this is met with some frustration and scratching of the head when trying to resolve your problems.

This is why we have really developers and tweaked our training classes over the years...to cover things just like this. 

At any rate, we are truly glad that you chose SF and we do appreciate your suggestions....this is how things get better!

Happy Easter...I am going to take off and spend the rest of the day with my family.  Talk to you soon.

I have not signed up yet, but it is on my priority list. 

In my experience with other training and developer conferences, it is best when you are familiarized with the tools, and that is just what I am doing know with this project, getting to know SF.  I belive I'll be in good shape for the July class.