Develop Reference

Storing format information in database for use within a Windows Form Application

I am struggling with how to handle formatting data pulled from a database when every customer may/will want their own formatting for some fields. I have googled around and have found the term data dictionary but no clear explanation of what this is or how I can leverage it in my C# / MSQL Server / Entity Framework windows form application. I feel like this must be a common problem, and therefore must be a standard or common way of handling this type of requirement.
Example:
I have a field called ReferenceRange (FLOAT) in a table. Customer X wants this field to be displayed with an accuracy of 2 decimal points and another would like this to be displayed with 1 decimal point of accuracy.

One way would be to create a parameter in you app.config file or a config table, them store in that place the customer preference.
On every ToString() read the customer preference decimals to create the corresponding format, like:
ToString("#,##0." + dec), where dec would be your stored value.

How can I properly present and write a checkboxlist to a db? (Theory/Logic help)

Please note that the database design I have now is fully in sandbox mode. Nothing is finalized. Everything (again this is in sandbox mode) is in one single table. Also, I'm in now way looking for coding help. I'm looking for the right theoretical/logical approach to this puzzle so I can go in and play with the coding myself. I learn better that way. If I need coding help, I'll come back here for further assistance.
I'm in the process of creating the first of a few CheckBoxList for a manually created form submittal. I've been looking over multiple ways to not only create said CheckBoxList but to enter it into the database. However, the challenge I'm facing (mainly because I haven't encountered this scenario before and I'd like to learn this) is that I not only need to worry about entering the items correctly in the database but I will eventually need to produce a report or make a printable form from these entries.
Let's say I have an order form for a specific type of Barbeque grill and I will need to send this form out to distriution centers across the nation. The distribution centers will need to pull said barbecues if they are highlighted on the form.
Here's what the CheckBoxList for the distibution centers will look like:
All
Dallas
Miami
Los Angeles
Seattle
New York
Chicago
Phoenix
Montreal
If the specific city (or all the cities) are checked, then the distribution center will pull the barbecue grill for shipment.
The added part is that I want to:
be able to create a grid view from this database for reporting to note which distribution center got orders for barbecues and
be able to create reports to tell what distribution center sent out barbecue orders in a given month (among other reporting).
Here's what I'm playing around with right now.
In my aspx page I have a checkboxlist programmed with all the distribution centers entered as a listitem as well as an option for 'ALL' (of the distribution centers).
I also created a dedicated column in this table that holds all the information in the listitem and programmed a sqldataconnection to this table to play with the programmability of leveraging the database for this purpose.
When it comes to writing the selections to the database, I originally created a column for each destination city including the 'All' option. I was toying around with just putting the selections into one single column but with some of the information I've been reading today about Database Normalization, the former options seems to be a better one than the latter. Is this correct practice for situations such as this especially if I need to think about reporting? Do I put the CheckBoxList data in one cell in a specific column? Do I create seprate columns for each distribution center? Am I even on the right track here?

Depending on the amount of cities that you want to store, I've used bitwise operators to store small amounts of data. Effectively, it would store it in the table like this:
CityID Location
2 Dallas
4 Miami
8 New York
16 Chicago
32 Montreal
and keep going in base 2 for additional cities.
When your user selects multiple cities for the order, the value that gets inserted into the database for cities is a bitwise OR calculation. So if they select Dallas, New York, and Chicago, you would be doing the following:
2 OR 8 OR 16
Which would equal 26
Now, you can use bitwise AND on the resulting value. So if checking for Miami the following is the evaluation:
26 AND 4 = 0
which indicates that Miami was not selected. Any value that was selected in the evaluation, it would return its ID like this:
26 AND 8 = 8
Again, I've only used this for small subsets of data, and to make the data storage as compact as possible. Computationally, it may be a trifle more expensive that some other methods, but I'm not 100% certain.

Note: This might not be the best approaches but I have seen them used.
1) Having one column of comma-delimited string
This should work well if the options don't have IDs in the database (having a separate referenced table)
You will need to loop through the checkbox list, obtained the selected options and concatenate them with String.Join()
You will need to split the string upon receiving it from the db and use it to check the checkboxes if there text is found in the resulting array
Problem: You might need a split function in the DB that converts the comma-separated string into rows. There split function implementation on the web/stackoverflow
2) You can have a separate table for the locations e.g. xxxxtable_location where the FK to the main table is referenced. This will be a one-many table
ParentID, Location
1 Dallas
2 Miami
2 New York
2 Chicago
3 Miami

Database design for handling individual and recurring charges

We have a billing system where we process individual charges as well as recurring charges (subscriptions).
There are two SQL tables:
StandardCharges
RecurringCharges
StandardCharges table holds individual items purchased by customers during the month.
RecurringCharges table holds recurring items with a charge by date. When the time comes our system automatically creates a recur request which adds a row to the StandardCharges table and increases the charge by date to next month in RecurringCharges table.
At the end of each month we get the total values for each customer from StandardCharges table and create an invoice.
Is there a kind of design pattern or another way of doing this? Is this the right database design? Ideally I would like to hold all charges in one Charges table and manage recurring charges from there as well?
Thanks

I suspect that your design is indeed correct.
When thinking about the data in real world terms it makes no sense to have "possible" transactions (I.E., transactions which have not yet happened and may not materialize, perhaps because the customer had overrun their credit limit) mixed in with committed and actual transactions.
Merging the data into a single table can also make reporting difficult as you have to apply special filtering criteria and store extra meta data - like TransactionCompleted and TransactionIsFutureCharge.
If I was to make a suggestion it would be renaming the StandardCharges to something closer to the data it holds like CompletedTransactions and the RecurringTransactions something like PendingTransactions.

The current design seems reasonable to me. But if you want to merge the two tables, you could simply add a BIT column called IsRecurring or IsFuture or IsScheduled or whatever you want to use to designate the charges that would have otherwise gone in RecurringCharges. Then when your due date is hit for a recurring charge, you just insert into the same table instead of a different table. As for the invoice, you'd just add a condition to the query to filter out the charges that have the BIT column set.

Need design suggestion for storing data for budget keeping application

I'm writing an application that I will use to keep up with my monthly budget. This will be a C# .NET 4.0 Winforms application.
Essentially my budget will be a matrix of data if you look at it visually. The columns are the "dates" at which that budget item will be spent. For example, I have 1 column for every Friday in the month. The Y axis is the name of the budget item (Car payment, house payment, eating out, etc). There are also categories, which are used to group the budget item names that are similar. For example, a category called "Housing" would have budget items called Mortgage, Rent, Electricity, Home Insurance, etc.
I need a good way to store this data from a code design perspective. Basically I've thought of two approaches:
One, I can have a "BudgetItem" class that has a "Category", "Value", and "Date". I would have a linear list of these items and each time I wanted to find a value by either date or category, I iterate this list in some form or fashion to find the value. I could probably use LINQ for this.
Second, I could use a 2D array which is indexed first by column (date) and second by row. I'd have to maintain categories and budget item names in a separate list and join the data together when I do my lookups somehow.
What is the best way to store this data in code? I'm leaning more towards the first solution but I wanted to see what you guys think. Later on when I implement my data persistence, I want to be able to persist this data to SQL server OR to an XML file (one file per monthly budget).

While your first attempt looks nicer, obviusly the second could be faster (depends on how you implement it). However when we are talking about desktop applications which are not performance critical, your first idea is definitely better, expecially because will help you a lot talking about maintaining your code. Also remember that the entity framework could be really nice in this situation
Finally if you know how to works with XML, I think is really better for this type of project. A database is required only when you have a fair amount of tables, as you explained you will only have 2 tables (budgetitem and category), I don't think you need a database for such a simple thing

Combine data from multiple sources, display in ASP.Net GridView

I am writing a currency converting module for one of our applications. I have a list of products, a list of currencies we are interested in seeing prices for, and a list of currency rates. I want the user to be able to select which currencies from the list they see in the GridView.
I also want to be able to amend my list of currencies and include a new currency, without having to make additional changes to this module. So my GridView display has to be dynamic.
Essentially I am planning on ending up with a GridView that has the following columns:
Part No - Description - USD Price - AUD Price - GBP Price
The USD price would be static as it's our base currency, the AUD and GBP are user selected and could have potentially any number of currencies listed.
I would normally use a DataSet and DataTables for this work, but I am sure there is a "better" way to do it using System.Collections.Generics.
Right now I have all of the data I need in List collections, but there does not seem to be a way to define how these collections relate to each other, or combine these collections into one so it can be bound to a GridView.
Should I be looking at something other than List to achieve this or do I need to go back to my original approach of a DataSet and DataTables.
Thanks!
******UPDATE / SOME CODE******
OK, someone asked for some code, so I will explain a little bit more about what I have setup so far.
List of Products & Currencies - These come from an SQL DB via LINQ, so they can be any of the System.Collections.Generics objects, e.g. List, IEnumerable etc.
Currency Rates - These I am pulling from the European Bank public XML file. I download the file, strip the data I need out of it and currently store that as a List object.
I could store the currency rates in the database table as well, but then I have to have some sort of background process that goes and updates the rates each day. This way the rates only get updated when someone accesses the report function (which is only going to happen occasionally). So I would rather grab the latest rates "on demand".
What I know I need to end up with is some object that has the following structure:
PartNo - Description - Base Price - Currency Price 1, Currency Price 2, Currency Price 3
Where the number of Currency Prices is undefined, as it's based on what currencies the user wants the report to display.
It's the undefined part that I am struggling with, essentially how can I create a structured object, that I don't know the complete structure of until runtime ?
Hope this makes more sense / helps!

Just thinking out loud here, but if you stored your "foreign" prices in a Dictionary or similar data structure like so:
class Product {
public String PartNo { get; set; }
public String Description { get; set; }
public Decimal BasePrice { get; set; }
public Dictionary<String, Decimal> ForeignPrices;
}
Then you could write a simple routine that would take a collection of the above objects and convert it into a DataTable that you could then bind to. Said routine would always create the following columns:
PartNo, Description, BasePrice
It would then loop through the items in the Dictionary, adding additional columns for each item. So if you had three items in ForeignPrices:
ForeignPrices.Items.Add("AUD", 10.50);
ForeignPrices.Items.Add("GBP", 6.20);
ForeignPrices.Items.Add("CAD", 5.95);
You would end up with three additional columns on your dynamically-created DataTable:
PartNo, Description, BasePrice, AUD, GBP, CAD
Of course you may want to do away with the BasePrice property and just make "USD" another item in ForeignPrices (in which case it would simply be called Prices).
HTH.