February 2003 - Posts
I just read an
article where KISS states pyro techy stuff is safe. Hey, if KISS says they are safe, then they are safe, being the pyro experts that they are.
I found this rather interesting
http://www.lights.com/weblogs/
Nice article by Dino Esposito
Follow the Top 10 ADO.NET Tips
I am going nuts over here. First, I run into all kinds of remoting issues with SqlParameter types. Now, I discover SqlConnection types are not remotable!!
Follow-up: Rudi was quick to point out the passing a connection from the client is BAD! I agree. In my case, I pass a conncetion string to a remoted server object and then build the connection object. I was simply testing passing the connection object, which, the more I think about it, this is not good. SqlParameters though, I see no reason why I would have concerns passing them as a SqlParameter type from my client, unless, of course, one is concerned about switching databases in the furture, which we will not.
I just discovered the Database Project Template in the VS.IDE. So far, it looks very nice for organizing and managing our database objects and integrating with VSS.
Check out:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vxoriDatabaseProjects.asp
So, I have developed a very nice data access component (SqlClient specific) that we have been using locally with great success. This week, I started testing using this same component remotely over http (IIS as the host). Some of the methods of this component expect SqlParameter types.
I have been getting all kinds of strange errors with remoting to these methods. I did a little research on SqlParameters. Come to find out they inherit from MarshalByRefObject, which means they are passed to the remoted object by reference, which means callbacks to the client! This kills performance, plus if you have a DMMZ, forget about it. The work around is to use a dictionary type for your sql params\values.
This really bugs me. I would think passing SqlParameters to s SqlClient Data Access component would be a common thing. Why are they not Value types?
Our workaround is to pass a hashtable with the paramname\value from the client to the remoted server object. Inside the remoted server object I have a function that does this:
Private Function BuildSqlParamArray(ByVal ht As Hashtable) As SqlParameter()
Dim arParms() As SqlParameter = New SqlParameter(ht.Count - 1) {}
Dim de As DictionaryEntry
Dim i As Integer = 0
Dim myParam As SqlParameter
For Each de In ht
myParam = New SqlParameter(de.Key.ToString, de.Value.ToString)
arParms(i) = myParam
i += 1
Next
Return arParms
End Function
So then I can pass an array of SqlParameters to the class my remoted object uses, which expects a SqlParameter array. This just seems hokey to me. it would be so much easier if SqlParamters were Value types.
I saw Sam's photos....wow...we were suppost to get that In Richmond, VA. We did not...thank God. Sam, I can mail you my shovel! Lucky for us our neighbor has one of those all terrain things with a snow blade and he loves to plow!
Here is a little show and tell on what we did get:
House1
House2
House3
If you look REAL close at the license plate on the Pathfinder, you will see the coolest plate in VA.
Death in the family, LAN blown to bits and the snow have kept me away, but I am back.
You know life is complete when you have made it to Amazon. I can slow down now, take it easy, so what lies ahead....yeah right! Look out for my "How to play better tennis'"series.......LOL.
This is a nice sample on building a DataAccess portal. It also provides some tips (indirectly) on how a smart client can determine if it needs to connect to a server object locally or remotely.
In our app, clients can be on the LAN or WAN; so we have decided to install the server side data objects locally and remotely and then, have a switch the client can set to tell the Client Data Portal where it can find the Server Data Portal. If they are remote, we look in the app.config file for the remote url and call RegisterWellKnownClientType. This works out very nice. We just set a ConnectionType Enum:
Public
Enum ConnectionType
LAN
WAN
End Enum
then create an instance of our Server data Portal:
Private
Shared mPortal As Server.DataPortal
We next check to see if it already exist, as this is a shared method:
If
mPortal Is Nothing Then
If it does not exist, find out if we are connection over WAN or LAN
If Connection = Connection.WAN Then
Dim svr As String = _
Where "PortalServer" is the remoted server url
ConfigurationSettings.AppSettings("PortalServer")
If Len(svr) > 0 Then
RemotingConfiguration.RegisterWellKnownClientType( _
GetType(Server.DataPortal), svr)
End If
End If
' if the connection type is LAN or WAN, we make it here. So, if it is LAN
' we will make it here regardless; meaning if it is or is not WAN it makes it here.
mPortal =
New Server.DataPortal()
Thanks Rocky!
Sowe lost our T1 connection today. I am using an Erols dialup. I think I actually saw dust blow out the back of my machine when the modem fire up. I had to spray some ether in the back to get it to go. Wow is this slow. I can remember 2-3 years ago modem was all I had and I never paid much attention to how slow it was.
Heck, I just installed a wireless network in my home and I got all pissy when I could not connect from deep in the backyard w/,y laptop. Wow, how quickly things change and how quickly we are progressing...if you want to call it progression.
More Posts
« Previous page -
Next page »