Develop Reference

C# match datagridview rows to access database

I am trying to figure out the best way to match items on a datagridview to items in an access database. (Think Quicken match transaction)
I import an excel sheet into a datagridview,from there it checks the access db looks for a match - if a match is found then it reports match in a column if not unmatched is reported.
i have tried to count the rows on an sql query - if = 1 then match is yes, but that for some reason will goof up sometimes.
so i am looking for the best way to do this.
Thanks - please let me know if you need any additional info.

There isn't a simple answer to this, and it depends on what your data looks like, and what you consider a "match" to be. As a very basic answer, this is one way to attack the problem. How far you take it is up to you...
Create an algorithm that takes all fields for a row and generates a "key" for it. For example if there are two fields [First], [Last] then perhaps the key would be "Bubba|Gump"
Apply that algorithm to both sets of data (the datagrid records and the access db records).
Compare the two sets of keys to determine what's identical/missing/added.
It's not foolproof but with some additional sophistication it'll take you surprisingly far.

One table or multiple tables for data having only one column change

I have four types of data's in a SQL Server Database Table: forum topic, article topic, chat topic and QnA Topic. These have same type of columns : ID, Title, Content, User,type etc. The only difference is the type column that is used to detect if the current content is forum topic(type = 0) or article topic(type = 1) and so on.
My colleagues said it will be better to store them in separate tables namely ForumTopics, Articles, Chats, QnAs. But in my view its not a good idea because the C# methods that are based on these content will be different and either I have to write multiple functions having same logic for each operation for each table or a conditional check in one function that its a forum topic(type = 0) or article topic(type = 1) or other.
Please tell me which is a better approach?

One table is better approach because it will give you flexibility in the future. You will be able to do things like the following:
Select everything for a particular user
Search something in all titles
Besides multiple tables are harder to maintain and you are right. There will be more complexity and repetition in your C# code as well with multiple tables.

Using one table is better way because it is difficult to maintain data if it is stored in separate table you have to write complex queries.
If you use multiple table you have to use joins or subquery to retrieve data which makes slow performance.
So go with a single table.

Best choice to store a list of ints in mssql

I am wondering which method is the best way to store a list of integers in a sql column.
.....i.e. "1,2,3,4,6,7"
EDIT: These values represent other IDs in SQL tables. The row would look like
[1] [2]
id, listOfOtherIDs
The choices I have researched so far are:
A varchar of separated value that are "explode-able" i.e. by commas or tabs
An XML containing all the values individually
Using individual rows for each value.
Which method is the best method to use?
Thanks,
Ian

A single element of a record can only refer to one value; it's a basic database design principle.
You will have to change the database's design: use a single row for each value.
You might want to read up on normalization.
As is shown here in the description of the first normal form:
First normal form states that at every row and column intersection in the table there, exists a single value, and never a list of values. For example, you cannot have a field named Price in which you place more than one Price. If you think of each intersection of rows and columns as a cell, each cell can hold only one value.

While Jeroen's answer is valid for "multi-valued" attributes, there are genuine situations where multiple comma-separated values may actually be representing one large value. Things like path data (on a map), integer sequence, list of prime factors and many more could well be stored in a comma-separated varchar. I think it is better to explain what exactly are you storing and how do you need to retrieve and use that value.
EDIT:
Looking at your edit, if by IDs you mean PK of another table, then this sounds like a genuine M-N relation between this table and the one whose IDs you're storing. This stuff should really be stored in a separate gerund, which BTW is a table that would have the PK of each of these tables as FKs, thus linking the related rows of both tables. So Jeroen's answer very well suits your situation.

XMLSerialized Object in Database Field. Is it good design?

Suppose i have one table that holds Blogs.
The schema looks like :
ID (int)| Title (varchar 50) | Value (longtext) | Images (longtext)| ....
In the field Images i store an XML Serialized List of images that are associated with the blog.
Should i use another table for this purpose?

Yes, you should put the images in another table. Having several values in the same field indicates denormalized data and makes it hard to work with the database.
As with all rules, there are exceptions where it makes sense to put XML with multiple values in one field in the database. The first rule is that:
The data should always read/written together. No need to read or update just one of the values.
If that is fulfilled, there can be a number of reasons to put the data together in one field:
Storage efficiency, if space has proved to be a problem.
Retrieval efficiency, if performance has proved to be a problem.
Schema flexilibity; where one XML field can eliminate tens or hundreds of different tables.

I would certainly use another table. If you use XML, what happens when you need to go through and update the references to all images? (Would you just rather do an Update blog_images Set ..., or parse through the XML for each row, make the update, then re-generate the updated XML for each?

Well, it is a bit "inner platform", but it will work. A separate table would allow better image querying, although on some RDBMS platforms this could also be achieved via an XML-type column and SQL/XML.
If this data only has to be opaque storage, then maybe. However, keep in mind you'll generally have to bring back the entire XML to the app-tier to do anything interesting with it (or: depending on platform, use SQL/XML, but I advise against this, as the DB isn't the place to do such processing in most cases).
My advice in all other cases: separate table.

That depends on whether you'd need to query on the actual image data itself. If you see a possible need to query on certain images, or images with certain attributes, then it would probably be best to store that image data in a different way.
Otherwise, leave it the way it is.
But remember, only include the fields in your SELECT when you need them.

Should i use another table for this purpose?
Not necessarily. You just have to ensure that you are not selecting the images field in your queries when you don't need it. But if you wanted to denormalize your schema you could use another table and when you need the images perform a join.

C# SQL: What is the best way to implement a dynamic table?

I want to allow the user to add columns to a table in the UI.
The UI: Columns Name:______ Columns Type: Number/String/Date
My Question is how to build the SQL tables and C# objects so the implementation will be efficient and scalable.
My thought is to build two SQL tables:
TBL 1 - ColumnsDefinition:
ColId, ColName, ColType[Text]
TBL 2 - ColumnsValues:
RowId, ColId, Value [Text]
I want the solution to be efficient in DB space,
and I want to allow the user to sort the dynamic columns.
I work on .NET 3.5 / SQL Server 2008.
Thanks.

I believe that is essentially how the WebParts.SqlPersonalizationProvider works, which doesn't necessarily mean it's the best, but does mean that after some smart people thought about it for a while, that's what they came up with.
Sorting on a given field will be a bit tricky, particularly if the field text need a non-text sorting (i.e., if you want "2" to come before "10").
I'd suggest that from C#, you do one query on ColumnsDefinition, and based on that, choose one of several different queries for selecting/sort the data.

Add a DefaultValue to your ColumnDefinition. Only add a value in ColumnsValues if the value is not the default value. This will speed up things a lot.
The thing I hate about these kind of systems is that it is very difficult to transfer changes betwween dev/stage/production because you will have to keep structure and content of tables in sync.