Re: Design question
From: Fred Hirschfeld (a_at_b.c)
Date: 01/31/05
- Next message: CBran: "Re: Displaying a popup from a windows service using .NET remoting"
- Previous message: Fred Hirschfeld: "Re: Winforms over LAN and Internet - Best approach? (WS, Remoting, etc)"
- In reply to: Joe: "Re: Design question"
- Next in thread: Joe: "Re: Design question"
- Reply: Joe: "Re: Design question"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 31 Jan 2005 08:23:57 -0800
SSPI is used in our current application and works quite well. We use a local
username and password on the App Server and Database server and synchronize
the password for each. The BEST way would be to have a domain account used
on each box instead of this but we do not have access to a domain controller
in the production area for this project. Microsoft allows a token to be
passed when the exact same username / password is used on two separate
machines (as we are doing). Let me know if you want more detail of exactly
how to set this up so you don't need a username/password in the connection
string.
I think the idea of object caching in memory is good as long as does not
over burden the machines memory and you have a mechanizm to recover if it
does get to a certain point.
As for the temp tables, are you doing processing between the sql statement
in code that could not be done in the Stored Procedure? If not I would
recommend using the stored procedure for security and performance reasons.
You can do a final select in the stored procedure (as I usually do) from the
temp table to return the final resultset. This will allow the stored
procedure to be compiled and execute faster than a bunch of calls to the
database.
Fred
As for the
"Joe" <J_no_spam@_no_spam_Fishinbrain.com> wrote in message
news:er1gK76BFHA.2428@TK2MSFTNGP14.phx.gbl...
> Currently I'm using a user/pw in the remote object to connect. I haven't
> come up with another means of doing this yet.
>
> Down the road, the data the end users get may be stored in memory outside
> the database and this object will be updated using notifications. But this
> is just a thought.
>
> Also, the #tmp tables aren't being created in a stored proc there being
> created by select ... into statements. The reason for this is that I need
be
> able to query the last table created which won't be there once the proc is
> done.
>
> Joe
>
> "Fred Hirschfeld" <a@b.c> wrote in message
> news:#vMZ6u6BFHA.3592@TK2MSFTNGP09.phx.gbl...
> > In my opinion using SingleCall with HTTP / Binary (in IIS) is the best
way
> > since you get more scalability but slight decrease in performance. I am
> > checking into compression for the Remoting calls to see if I can gain a
> > small amount of the performance back by adding a compression sink to zip
> the
> > messages.
> >
> > If you are using the SQL Server #tmpTables in a stored procedure then
you
> > should be good with any approach for Remoting as you will start a new
> > connection each time you call to it. A Singleton with a constant
> connection
> > may not be good but I am not 100% sure (probably not good performance or
> > resource usage).
> >
> > In your connection string, are you supplying a single username/password
or
> > using SSPI? If SSPI are you configuring the Remoting Host with a
username
> > that can access the database (best for Connection Pooling) or using
> > Impersonation to pass the credentials to the SQL Server?
> >
> > Fred
> >
> > "Joe" <J_no_spam@_no_spam_Fishinbrain.com> wrote in message
> > news:uuhgFHwBFHA.2112@TK2MSFTNGP09.phx.gbl...
> > > they're #tempTables and only needed for a single call (so far).
> > >
> > > I did manage to get it working again. I actually had my connection
> string
> > > wrong BUT I would still like to know the best approach for this.
> > >
> > > Thanks,
> > > Joe
> > >
> > > "Fred Hirschfeld" <a@b.c> wrote in message
> > > news:uO#js$vBFHA.2180@TK2MSFTNGP10.phx.gbl...
> > > > Are these temp tables used in stored procedures using the #tmpTable
> > syntax
> > > > or have you got DDL creating real tables as temp tables? Do these
temp
> > > > tables have to remain after one call to remoting so on subsequent
> calls
> > > they
> > > > remain there?
> > > >
> > > > Fred
> > > >
> > > > "Joe" <J_no_spam@_no_spam_Fishinbrain.com> wrote in message
> > > > news:OCHOXwvBFHA.2180@TK2MSFTNGP12.phx.gbl...
> > > > > I have a remote object which connects to a Sql database. This
object
> > is
> > > > > supposed to return records back to the client. Simple enough.
> > > > >
> > > > > My problem is that each client should maintain its own connection.
I
> > > can't
> > > > > use a shared connection because there are many temp tables created
> per
> > > > > client.
> > > > >
> > > > > I had tried using SingleCall which was working when the object was
> > > hosted
> > > > on
> > > > > one machine but once I moved it to another server it no longer
works
> > > > right.
> > > > >
> > > > > What is the best approach for handling this?
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: CBran: "Re: Displaying a popup from a windows service using .NET remoting"
- Previous message: Fred Hirschfeld: "Re: Winforms over LAN and Internet - Best approach? (WS, Remoting, etc)"
- In reply to: Joe: "Re: Design question"
- Next in thread: Joe: "Re: Design question"
- Reply: Joe: "Re: Design question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
