DataAdapters and Parameters

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm creating a simple search for Members, with possible 4 search parameters:
Name, SSN, DOB, SEX, but (just beginning ASP.NET/VB.NET) I'm fearing that I
will need to create a dataadapter for every possible combination of fields
entered to eliminate a blank parameter.

Does a parameterized DataAdapter automatically take care of this so I can
use the following SQL without having to worry about blank textboxes?:

SELECT * From Membership WHERE
Name = @txtName AND
SSN like @txtSSN AND
DOB like @txtDOB AND
SEX like @txtDOB

Perhaps a DataReader is more appropriate for this?

Presently, in my Access application, I've had to write a separate strSQL for
each possible combination as to avoid creating a SQL statement with a blank
parameter.

Additionally, since this will be an Intranet application which needs
downtime backup, that is why I am currently working with Access. I'm hoping
for the user to use SQL server while the intranet is up, and have a downtime
backup of this info in an MDB file on their local hard drive.

Thanks so much for anything to help with this...
 
Does a parameterized DataAdapter automatically take care of this so I can
use the following SQL without having to worry about blank textboxes?:
Click to expand...

No. Your DataAdapter will work exactly per the SQL Statement you specify.
Perhaps a DataReader is more appropriate for this?
Click to expand...

I don't see why .. this factor is certainly not a consideration in choosing
between dataadapter or datareader.
Presently, in my Access application, I've had to write a separate strSQL
for
each possible combination as to avoid creating a SQL statement with a
blank
parameter.
Click to expand...

So you are using MS-Access? Try Like %xx%
Additionally, since this will be an Intranet application which needs
downtime backup, that is why I am currently working with Access. I'm
hoping
for the user to use SQL server while the intranet is up, and have a
downtime
backup of this info in an MDB file on their local hard drive.
Click to expand...

I'm so confused. If this is an ASP.NET App, you shoudln't be using Access,
and if there is downtime - then the webserver is down - why bother with MS
Access?

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
 
Ok. The application is for a business that heeds to check on a member's
current valid membership. It doesn't need to be in Access.
But since the checking of this validity will not be via the Internet and on
an Intranet, downtime needs to be considered. There are times when the
server goes down and we need to check a customer's membership.

I'm beginning, with .NET so please take the time to explain something better
if you know of anyway. I'm thinking that during normal "uptime" when servers
are optimal, using SQL Server and ASP.NET via our intranet. When the servers
go down, is it possible for ALL MEMBER's never accessed before to be
available with that set up?

I guess I could go with a synchronized SQL database?...
Well as of now, the SQL portion hasn't been given to me and the only thing I
have for my development is MS Access as my Backend, so I'm prototyping right
now.

Could you suggest a model for this situation?
 
Jonefer,

Well, so I'm assuming that this is a client server app based on the intranet
... rather than a web based app - and downtime is when the server is down,
but the clients are up.
If that is the scenario, I would suggest looking into SqlMobile. As Bill
Ryan - http://msmvps.com/williamryan about synchronization etc. in
SqlMobile.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
 
Jonefer:

I'm not sure I fully understand the problem but I'll do what I can to help.
We did a proof of concept for a state agency where the app would use Sql
Server as the back end. But, it was both tablet PC and desktop enabled so
it used Sql Mobile as well. If there was network connectivity , then it
would use the big Sql Server, otherwise it would use the Sql Mobile
instance. When network connectivity was re-established, then it would sync
the dbs up and use the server instead. Is this sort of what you're looking
for?

Also, depending on the size of the tables, you may be able to load the
membership tables in as public static properties and just check them. Take
this example:
We have an application where users log in and out maybe 5-15 times a day.
We have to expire them b/c of security mandates. Anyway, so people may log
in more than that. There are about 400-500users on a given day. Each time
they log in, we grab profile information about them as well. When the app
first came to be, we made a db hit each time someone logged in to
authenticate them and do everything else. Now, we just add their row to the
db each time they log in for the first time. So now, b/c we store it in a
datatable, instead of hitting the db 15 times a day for each person to grab
the exact same information, we only do it once. ADO.NEt lends itself quite
well to this (statics in ASP.NET for instance are shared throughout all
applications, but even in winforms, a datatable can be used throughout an
application session). Using the caching application block helps out too.
Depending on the nature of your data, you may be able to use something like
this to address your concerns.

Sql Mobile is an excellent way to handle 'sometimes connected' situations if
that's what you experience, but if this is an intranet application, I'm not
sure it's the way to go - somehow I'm guessing that your servers don't go
down that often.

Can you tell me a little more about your case and I'll try to work through
it with you.

If you go to my blog - you can contact me through the contact link or use
William Ryan AT Gmail Do t com.
I'll do what I can to help.

Cheers,

Bill
 
Back
Top