Wow!
I want a Mac for Christmas:
Just kidding.
Senseless babblings from a guy who breathes, eats, and sleeps around computers.
Scenario:
Why someone would design a flight number assignment algorithm such that any X flight departing XXX for YYZ at time hh:mm, on any day of the week, would get assigned the exact same flight number, is beyond me. Are flight numbers so scarce that they have to reuse the same numbers every day?
I’ve been dabbling with the ADO.NET Entity Framework in .NET 3.5, was trying to convert this SQL WHERE clause, which uses the LIKE operator, into LINQ syntax:
String strWhereClause = String.Format(CultureInfo.CurrentCulture, "Type={0} AND Name LIKE '*{0}*'", orgType, orgName);
I read somewhere which suggested to use the SqlMethods helper class. So I tried:
var objQuery = repository.Organization.Where(vendor => vendor.Type == orgType && SqlMethods.Like(vendor.Name, "”%” + orgName + “%”));
The query is targeting an Organization table. repository is an instance of an ObjectContext subclass which has been auto generated by Visual Studio’s ADO.NET Entity Data Model wizard. orgType and orgName are passed-in parameters.
The above approach resulted in the following runtime error (notice the redundant occurrence of the word ‘method’ in the error message):
LINQ to Entities does not recognize the method 'Boolean Like(System.String, System.String)' method, and this method cannot be translated into a store expression
I then saw a post on stackoverflow which suggested to use Contains(), StartsWith(), or EndsWith() to mimick the LIKE operator. So I tried:
var objQuery = repository.Organization.Where(vendor => vendor.Type == orgType && vendor.Name.Contains(orgName));
This works, but if orgName.Length is zero, then the query returns zero rows. So finally, a slight mod to the above query achieved the desired effect:
var objQuery = repository.Organization.Where(vendor => vendor.Type == orgType && (orgName.Length == 0 || vendor.Name.Contains(orgName)));
I’m deploying my ASP.NET app to a brand new server with a fresh install of SQL Server 2008 Express. The db connection step failed with this error:
Message: The underlying provider failed on Open.
StackTrace: at System.Data.EntityClient.EntityConnection.OpenStoreConnectionIf(Boolean openCondition, DbConnection storeConnectionToOpen, DbConnection originalConnection, String exceptionCode, String attemptedOperation, Boolean& closeStoreConnectionOnFailure) at System.Data.EntityClient.EntityConnection.Open() at System.Data.Objects.ObjectContext.EnsureConnection() at System.Data.Objects.ObjectQuery`1.GetResults(Nullable`1 forMergeOption)
I checked the connectionString, which uses Windows authentication, and it looked fine.
Somebody suggested to Allow Remote Clients in the Network DTC Access settings. That option is already enabled on my environment.
I looked at the Event Viewer, and noticed this entry:
Event Type: Failure Audit
Event Source: MSSQL$MSSQL
Event Category: Logon
Event ID: 18456
User: NT AUTHORITY\NETWORK SERVICE
Description:
Login failed for user 'NT AUTHORITY\NETWORK SERVICE'. Reason: Failed to open the explicitly specified database. [CLIENT: <local machine>]
So IIS is trying to access the database under the credential 'NT AUTHORITY\NETWORK SERVICE' . I looked that the db settings via SQL Server Management Studio and, sure enough, that account is not listed as one of the users allowed to connect. So I added him. And the web app was able to connect successfully.
Normally this goes in the App.config. VS2008 designer wizard automatically creates this file and puts it in the same location as the assembly in which your database layer resides. But if you’re calling that assembly from an ASP.NET app, you’ll need to move that connectionString to the Web.config. Otherwise, you’ll get this error upon instantiation of the ObjectContext:
The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.
Just watched the Google Wave demo, via @tylerwhitaker. Board game playing via email--I've thought of this before but seeing it implemented with Wave is so much cooler!
I've learned over the years, through the many facets of my job, to don a different hat depending to whether I'm talking to a programmer, a business person, or an end user.
Which is why it always freaks me out when I see my fellow developers showing my CEO how to run regasm to get a particular new product feature to work. Good God!
I guess in some sense it's good, because now when something is not working quite right, my CEO would ask "Do I need to rerun regasm?"
I’m debugging a Windows hook DLL that’s misbehaving. Actually I’m still not sure whether it’s the hook DLL, or the C# library that calls it, that is the culprit. Here’s the problem symptom. My app DLL installs a mouse hook into a running application. The running app terminates. My app detects that it has terminated and attempts to remove the hook—this fails (1). On subsequent startup of the app in question, I try to re-install the hook onto it, and that fails (2). I’m actually more interested in failure #2 than failure #1, but the latter is probably a consequence of the former. So I needed to track down why #1 happened.
Side fact:
When you install a thread-specific Windows hook, your hook DLL is actually loaded in 2 places: one instance is loaded in your app's process space, and the other in the target app's.
At first, I thought that Windows was failing to do its DLL cleanup duties when the unhook step failed, so I was ready to look into manually forcing the unload and reload of the native DLL—often a bad idea to circumvent the garbage collector, but, hey, what else can you do?
Then I spotted the culprit:
DLLEXPORT HHOOK SetHook(HWND hWndTarget, HWND hWndListener) {
if(m_hWndListener != NULL) return NULL; // already hooked!
// install the hook via SetWindowsHookEx()
…
…
m_hWndListener = hWndListener;
…
}DLLEXPORT BOOL ClearHook(HHOOK hook) {
BOOL unhooked = UnhookWindowsHookEx(hook);
if (unhooked) {
m_hWndListener = NULL;
// do other cleanup stuff
}
return unhooked;
}
It turned out: m_hWndListener was not being cleared when UnhookWindowsHookEx() failed.
Yet again, it goes to show that: just when I thought that the developers at Microsoft are a bunch of idiots who had no clue what they were doing when they invented the Windows API, it turns out that the idiot is me.
As to why UnhookWindowsHookEx() failed, my guess is that the hook was already being automatically removed by the OS when the target app terminated.
© 2004-2009 Thanh Hai Tran.
All Rights Reserved.
Kubrick Blogger Template by GeckoandFly.
Disclaimer:
The opinions expressed on this blog are mine alone,
and do not necessarily reflect those of my employers.