string truncation
-
So far this is the best approach I have come up with (untested!): 1. I'll have my app interrogate the DB structures at startup to basically set up a
Dictionary<string tableName, Dictionary<string fieldName, int fieldLength>> stringMaxLenghts;
That isn't too much trouble, I already have a number of run-time checks for the presence of some tables and some fields (the database is going to exist in many generations). 2. For each relevant TextBox I'll have each of my dialog Load handlers call a static method:
StaticClass.SetTextBoxMaxLength(TextBox textbox, string tableName, string fieldName) {...}
which sets the TextBox.MaxLength property in accordance to the stringMaxLenghts information. That will eventually cause some beeping at the very moment the user is typing too much text. Not that I like beeping a lot. 3.In the data layer, I'll have my DatabaseCommand.AddStringParameter(...) methods check the length of the string against stringMaxLenghts once more (and truncate if necessary); this to be safe in case some data slips through, e.g. something that doesn't come straight from a TextBox. That seems a reasonable cost (only one Dict-of-Dicts being passed, plus a number of method calls in Load handlers) to accomplish most of what I want. Comments are welcome. Better ideas too. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Good strategy. Item 3 is probably not required, but a good catch-all nonetheless...
Luc Pattyn wrote:
stringMaxLenghts
Has a typo in it. stringMaxLengths
Silence is golden... but duct tape is silver!! Booger Mobile - My bright green 1964 Ford Falcon - check out the blog here!! | If you feel generous - make a donation to Camp Quality!!
-
it is WinForms that does the beeping, I don't add to it. I know I could add a "chars remaining" indicator (and I do appreciate those on the web sites that have them, e.g. the CP forum's signature editor), but then that would really alter and enlarge all my dialogs, I don't want to do that. However I could use a TextBox derivative in a few occasions, that would fit nicely with the current scheme. So phone numbers and ZIP codes would beep on abuse only, whereas big TextBoxes (e.g. a comment field) might be more civilized. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Luc Pattyn wrote:
might be more civilized.
Ah, yes, maybe on KeyDown or something.
-
Good strategy. Item 3 is probably not required, but a good catch-all nonetheless...
Luc Pattyn wrote:
stringMaxLenghts
Has a typo in it. stringMaxLengths
Silence is golden... but duct tape is silver!! Booger Mobile - My bright green 1964 Ford Falcon - check out the blog here!! | If you feel generous - make a donation to Camp Quality!!
Thanks for the heads up. I'll give it a whirl tomorrow. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
String or binary data would be truncated is the nice SqlException one gets from SQL Server when attempting to insert/update a record with a string value that is longer than the field is wide. That raises 3 questions: 1. what would be the recommended approach in general? 2. what would be the recommended approach in a medium-size application (lots of insert/update statements, no SP), when the user doesn't care much and would be happy when the strings where truncated without notification? 3. is there a simple way to identify which field is overflowing? TIA
Luc Pattyn [My Articles] Nil Volentibus Arduum
Wouldn't it be a better idea to have a model layer that sits in between the data access layer and the GUI. The properties in the model layer would know the limits of their respective database fields, and pass this on via an interface such as IDataErrorInfo or something similar. This way you can have GUI validation.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
Wouldn't it be a better idea to have a model layer that sits in between the data access layer and the GUI. The properties in the model layer would know the limits of their respective database fields, and pass this on via an interface such as IDataErrorInfo or something similar. This way you can have GUI validation.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
Thanks Wayne. Yep, that is the way it seems to be evolving. I already discovered I could make most of my business objects derive from a base class (say DatabaseRecord), which could help taking care of general field information handling. I'd still appreciate an example though, so if you're aware of some article I should read, please let me know. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Thanks Wayne. Yep, that is the way it seems to be evolving. I already discovered I could make most of my business objects derive from a base class (say DatabaseRecord), which could help taking care of general field information handling. I'd still appreciate an example though, so if you're aware of some article I should read, please let me know. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
I have a basic article on the IDataErrorInfo that follows the MVVM pattern Validating User Input - WPF MVVM[^] that should get you started. Good Luck!
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
I have a basic article on the IDataErrorInfo that follows the MVVM pattern Validating User Input - WPF MVVM[^] that should get you started. Good Luck!
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
Ah. That looks interesting. Thanks very much, I'll have to read that in the morning, and apply it right away. :-D
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
jschell wrote:
a much better idea is to validate the data first
In theory sure. However it seems to imply the GUI knows all the database field widths, or alternatively the DB knows how to identify the failing field and pass that on to the GUI. Hence my third question. :doh:
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Maybe I didn't explain well enough, but it isn't a one-off situation that I am trying to resolve. My app holds a number of tables and dialogs; each dialog holds TextBoxes (and other Controls), and the strings entered in the TextBoxes is going to be inserted or updated in the tables. Think of people's first and last name, addresses, phone numbers, a comment line, some preferences, and many more. Right now there is no protection against overflow, as TextBoxes allow an unlimited amount of text to be entered (and the GUI is unaware of the table field widths anyway). So it is at run-time that the users might enter too much text in any of a large number of fields; the fields are quite sufficient for the intended use, but nothing is preventing abuse. So I want: 1. to make sure my app behaves well no matter what the input is; 2. provide detailed feedback where necessary (such as "Phone number cannot exceed 50 characters"). One way to remedy the situation would be to populate, at start-up, some data structures describing all relevant field widths, and pass this to the GUI stuff, so it can check all the lengths and warn the user, before attempting an insert/update. However that seems more effort than elegance, hence me asking about some best practices and/or easy solutions. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Luc Pattyn wrote:
One way to remedy the situation would be to populate, at start-up, some data structures describing all relevant field widths, and pass this to the GUI stuff, so it can check all the lengths and warn the user, before attempting an insert/update. However that seems more effort than elegance, hence me asking about some best practices and/or easy solutions.
Generate the database API from the database schema. At the same time, and in a different API, generate validation classes. That includes length validation and not null validations but does NOT include things like foreign key constraints. The validation classes are used in the database API before attempting to apply the data to the database. They can also be used elsewhere, because they represent their own API. This idiom probably works better in a standard distributed arch versus stand alone but the idea still applies. At any rate that is how I do it and have done it that way for years in a variety of different languages. But that is how I do it so it is "easy". The "best-practice" is still - validate it. How you achieve the validation and insure its correctness is a different matter.
-
Luc Pattyn wrote:
In theory sure. However it seems to imply the GUI knows all the database field widths,
My applications always have a database API. That API would be the place to insert validation including limit checks.
Yes, I am implementing that right now. Thanks. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Luc Pattyn wrote:
One way to remedy the situation would be to populate, at start-up, some data structures describing all relevant field widths, and pass this to the GUI stuff, so it can check all the lengths and warn the user, before attempting an insert/update. However that seems more effort than elegance, hence me asking about some best practices and/or easy solutions.
Generate the database API from the database schema. At the same time, and in a different API, generate validation classes. That includes length validation and not null validations but does NOT include things like foreign key constraints. The validation classes are used in the database API before attempting to apply the data to the database. They can also be used elsewhere, because they represent their own API. This idiom probably works better in a standard distributed arch versus stand alone but the idea still applies. At any rate that is how I do it and have done it that way for years in a variety of different languages. But that is how I do it so it is "easy". The "best-practice" is still - validate it. How you achieve the validation and insure its correctness is a different matter.
That makes a lot of sense. I'm adding a model layer with validation right now; it will not be all automatically generated, however first results are good, and I think it will fit for right now. Anyway, thanks a lot for the insights. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Thanks Wayne. Yep, that is the way it seems to be evolving. I already discovered I could make most of my business objects derive from a base class (say DatabaseRecord), which could help taking care of general field information handling. I'd still appreciate an example though, so if you're aware of some article I should read, please let me know. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
I agree with Wayne, your model should be aware of your data structure and it's limitations. As I always us stored procs that are generated this is a simple excercise, the generator reads the table info from the database meta data and creates the CRUD procs , the model code and the DAL (executes the procs and returns a list<> of the object).
Never underestimate the power of human stupidity RAH
-
I agree with Wayne, your model should be aware of your data structure and it's limitations. As I always us stored procs that are generated this is a simple excercise, the generator reads the table info from the database meta data and creates the CRUD procs , the model code and the DAL (executes the procs and returns a list<> of the object).
Never underestimate the power of human stupidity RAH
Thanks. I'm fully convinced by now that is the right way to do things. And I have implemented parts of it already, the TextBoxes now are fully aware of the field widths through a simple model layer and some dictionaries. While not fully automatic, it seems to work well. :thumbsup:
Luc Pattyn [My Articles] Nil Volentibus Arduum