Dataview rowfilter dates

[Astie]

i've got 2 questions in once:

i use VS.NET and having an ms database (if you need this information)

1. i want to filter a row with a dataview.rowfilter. I know how to do this with normal text fields but not with date's. I've got a combobox with the 12 months in it, now when i click for example may, i want the rowfilter to filter al the date's with the 5th month in it like 10-5-2005 and 30-5-2005 etc. how do i do this because = and like statements don't work. i get the next message:

Additional information: Cannot perform '=' operation on System.DateTime and System.Int32.


2. What ar al operators that you can use with a rowfilter, alike = and like?

 

[cjard]

I don't understand what you mean by this.

When you go shopping for.. say.. shoes, do you walk straight in, up to the counter and say "i'll buy all the shoes in the stock room, including those not in my size", take them all home and then look through all the boxes for the ones you want to wear, and leav ethe rest in the wardrobe (or garage, if it was a big shop?)
Why not just say to the shop assistant "please get me the Dandy style, Tan color, Size 5" from the stock room ? She knows how they are organised, she can find them faster than you, and you dont have to carry 4000 pairs of shoes home just to eventually use one pair that you want.

Using the dataview.rowfilter isn't slower than connecting to the database, using the select statement, every time I want to filter the records.

On anything other than a small dataset, you might be surprised. Filter does have its uses, but I dont envisage this to be one of them. Maybe I cant be accurate about that because I dont truly know your context.

I'd never assert that .Filter is faster than a database search though, because the SQL that performs a search is compiled and planned, using artificial intelligence created by some of the most brilliant minds in the industry at a cost of millions of dollars. Filter, on the other hand, is interpreted for every row, not compiled, and knocked together as a free and simple add-on to a small part of a very large framework written by a bunch of guys on a budget with more on their mind than lightning search performance..

I don't want to slow things down by connecting to the database every time the user changes their search options.

What makes you think a database search is slow?

I will be filtering and unfiltering the same in-memory records over and over.

What makes you think a filter is quick?

Ends up, you found your solution, and that's good.. I dont need to reply to this thread any more, and I dont think my questions are prompting much thought or investigation beyond blind assumption :/

 

[KimmyGoose]

I see and understand what your saying about querying the database every time instead of grabbing all records and filtering them. The context that I am in is this; There is only every one user at a time and there are no network or shared database files involved. This is a college club membership database which only holds names, phone numbers, graduation year, and a few other bits of information. There will be a new database every semester so I can't imagine there being any more than 100 to 200 records total in the database at a time. When filtering/querying the number of records returned would max out at about 10 to 40 results at most. Since this is a small application than I think ya'll think, would it still be wise to query the database rather than to filter? Because of the size would there even be much of a difference in the first place?

By the way, thanks for ya'lls help. I'm making a lot of progress here which is good. I have until the end of the summer to write this.

 

[Arg81]

You can look at it two ways (maybe more i dunno )

1) Use ADO.net how it should be used from the beginning, even if it's not a requirement to use parametised queries to reduce the data loaded (this is the "correct way" ! )

2) As it's a small app, just load ALL the data there and then and filter using the program.

Now, by doing it correctly to start with, you get into a routine and an understandable habit.
You may get a bigger project to do, and if you've learnt to use ADO.net in the sense of "Fill All and Filter All" then you REALLY will get issues on those bigger problems.

Personally I'd do it using parameterised queries. That way you get to understand how they work should you require to use them / expand your app at a later date.

Glad to hear you're learning, although sometimes posts come across out of context, they are there more for the poster to try and work out and challenge themselves, instead of having an easy ride and someone saying "yep I know how to do that, here's the code".

 

[cjard]

I can't imagine there being any more than 100 to 200 records total in the database at a time

One thing you'll learn in industry: That scrappy, beta, stopgap quick-hash app you threw together to demo a concept will still be in use 2 years and a million rows later. Try to make it scaleable from the outset!

Since this is a small application than I think ya'll think, would it still be wise to query the database rather than to filter?

Yep.. Practicing for when you work on bigger apps.

Because of the size would there even be much of a difference in the first place?

True, plus the DB is local, so there isnt even the speed of the network to consider, just the speed of the hard disk.