linq behavior: mapping table needs a PK set for FK associations to work

Like the previous, this is with 3.5SP1.  Also, I “get” that this is probably By Design as lacking the PK you’re unable to identify specific rows in the mapping table for later update, but for the purpose of this blog post I’ll consider it a bug anyway 🙂

This one didn’t take as long to figure out since I luckily had working and broken test cases already in front of me to compare.

One mapping table (basically just 2 columns holding the PK’s of 2 “real” tables to create a n:m mapping) didn’t have a PK set, and even with all 3 of them in the dbml, the FK associations (the FK’s were set fine) weren’t working – it would show the PK columns in the table’s class fine, but not the properties (of the type of the parent tables) that should be there “following” the FK links.

Another mapping table, very similar, though, had a PK set (encompassing the 2 FK columns instead of a pure-identity 3rd column) and its associations Just Worked.

Sure enough, I took the 2 FK columns, made those into a PK, then removed/readded that table in the dbml, and now the FK associations work fine!

Here’s an example repro: 2 real tables with simple PK int’s and a mapping table that just FK’s to each of them.

Notice here at the start that there’s no PK set for the mapping table, just the FK’s to the 2 real tables.

image

The FK relationships work fine as-is, at least in terms of SQL Server and even the dbml diagram showing them.  Notice that both real tables have PK’s set (the key-looking icons to the left of the id columns), but there’s no PK set for the mapping table.

image

However, when we actually try to use the mapping table, you’ll notice we only get the FK int’s and not the actual “real” table classes that we’d expect from LINQ-to-SQL:

image

Now, to confirm that adding the PK actually fixes it. So, we pick the 2 columns and make that a PK in the mapping table.

image

image

Now, this is one of the painful things about LINQ-to-SQL as opposed to LINQ-to-Entities – no “refresh from schema” option.  It’s not likely to show up, since the ADO.NET team’s made it clear that LINQ-to-Entities are the future.

Ok, back to manually refreshing (remove then add) the table in the dbml.

This is another behavior that appears to be a bug in VS – after setting the PK in SSMS fine, it doesn’t matter what you refresh in the connection, dragging over the mapping table won’t show the PK change.  While I could probably delete/re-add the data connection in server explorer, I just restart VS to do the trick.  Afterwards, adding the table shows the PK fine:

image

Save that dbml change, and now we can “see” the associated tables, not just the FK’s:

image

Advertisements

LINQ-to-SQL bug with stored procedures (sprocs) – must have named columns in returned result sets

This is with 3.5SP1, and unfortunately it took me most of the day to figure out.

While it looks like LINQ-to-SQL (SqlMetal in this case, I assume) supports sprocs that return “raw” (unnamed) columns, naming them Column1 through ColumnN, at runtime they don’t actually get populated with the real data, leaving them always as default(T) for their type.

The easiest way to explain it is to show the repro cases:

Source of the (painfully simple) sprocs:

CREATE PROCEDURE GetRawColumns
AS
    SELECT 1,2,3
GO

CREATE PROCEDURE GetNamedColumns
AS
    SELECT 1 as a,2 as b,3 as c
GO

C# calls to them once they’re added to the dbml (using the UI to drag-drop the sprocs from Server Explorer in this case)

var raw = db.GetRawColumns();
var rawList = raw.ToList();

var named = db.GetNamedColumns();
var namedList = named.ToList();

Actual runtime (in the debugger) values:

image

I haven’t tried mixing named and unnamed columns or anything like that – this blog post represents as much time as I’m willing to put into the bug now that I know a workaround 🙂

eTrust signature downloads for Windows are broken – hacked or user error?

http://etrustdownloads.ca.com/legacy/av/

Pasting the actual file list here since hopefully it’s fixed soon.

The full virus signature update file normally runs around 20MB and the incremental runs around 6 or 7MB.  If you look at the below list for the fi_* files, you can see that the files look to be about the right size except for 3 particular files which just happen to be the targets I would pick if I were doing an attack: Win 9x, Windows (NT, so that includes NT and every after, like 2000, XP, 2003, 2003 R2, Vista, 2008, 2008 R2, and 7), for x86 and Windows (NT, same list) for x64 / amd64.  Those files are all 195k, which I’m assuming to be a file with no actual signatures in it. 

You’ll see the same file size of 195k show up for all the *nt86* and *w9x* files, with the *ntamd64* files all coming in at 181k, also likely to be empty (especially since it’s even smaller).

Whatever the reason, it’s pretty scary if you’re someone that trusts (pardon the pun) eTrust to keep your computer safe.  Given that the other OS’s (Linux, MaxOSX, SunOS, HPUX, etc) aren’t affected, it sure smells like an attack, but we’ll see.

The one silver lining seems to be that eTrust isn’t actually updating its signatures from these presumably-empty files, so I’m “only” a week out of date, but if it were an attack, I’d say CA is just lucky in that regard.

Which is worse, though?  User error or attack?  User error, presumably because it’s a HR or process problem @ CA?  Or an attack, presumably because CA isn’t properly securing (and, worse, independently checking the sanity of) a host critical to the security of their customers?

</soapbox>

Index of /28859/etrustdownloads.ca.com/legacy/av

   Name                              Last modified        Size

[DIR] Parent Directory 29-Apr-2009 19:38 1k [DIR] 7.1/ 06-May-2009 10:12 1k [FILE] Siglist.txt 06-May-2009 09:10 1k [FILE] Siglist2.txt 06-May-2009 09:10 2k [FILE] fi_Linux_390.tar 06-May-2009 04:44 21.9M [FILE] fi_Linux_i386.tar 06-May-2009 04:44 21.5M [FILE] fi_MacOSX.tar 06-May-2009 04:44 20.9M [FILE] fi_MacOSX_i386.tar 06-May-2009 04:44 20.8M [FILE] fi_SunOS_sparc.tar 06-May-2009 04:44 21.4M [FILE] fi_hpux_parisc.tar 06-May-2009 04:44 22.3M [FILE] fi_nt86.exe 06-May-2009 10:11 195k [FILE] fi_ntamd64.exe 06-May-2009 10:11 181k [FILE] fi_ntia64.exe 06-May-2009 04:43 15.4M [FILE] fi_nw.zip 06-May-2009 04:44 14.8M [FILE] fi_w9x.exe 06-May-2009 10:11 195k [FILE] fv_Linux_390.tar 06-May-2009 04:44 21.9M [FILE] fv_Linux_i386.tar 06-May-2009 04:44 21.5M [FILE] fv_MacOSX.tar 06-May-2009 04:44 20.9M [FILE] fv_MacOSX_i386.tar 06-May-2009 04:44 20.8M [FILE] fv_SunOS_sparc.tar 06-May-2009 04:44 21.4M [FILE] fv_hpux_parisc.tar 06-May-2009 04:44 22.3M [FILE] fv_nt86.exe 06-May-2009 10:11 195k [FILE] fv_ntamd64.exe 06-May-2009 10:11 181k [FILE] fv_ntia64.exe 06-May-2009 04:44 15.4M [FILE] fv_nw.zip 06-May-2009 04:44 14.8M [FILE] fv_w9x.exe 06-May-2009 10:11 195k [FILE] ii_Linux_390.tar 06-May-2009 04:44 6.7M [FILE] ii_Linux_i386.tar 06-May-2009 04:44 6.7M [FILE] ii_MacOSX.tar 06-May-2009 04:44 6.7M [FILE] ii_MacOSX_i386.tar 06-May-2009 04:44 6.7M [FILE] ii_SunOS_sparc.tar 06-May-2009 04:44 6.7M [FILE] ii_hpux_parisc.tar 06-May-2009 04:44 6.7M [FILE] ii_nt86.exe 06-May-2009 10:11 195k [FILE] ii_ntamd64.exe 06-May-2009 10:11 181k [FILE] ii_ntia64.exe 06-May-2009 04:44 6.2M [FILE] ii_nw.zip 06-May-2009 04:44 5.8M [FILE] ii_w9x.exe 06-May-2009 10:11 195k [FILE] iv_Linux_390.tar 06-May-2009 04:45 6.7M [FILE] iv_Linux_i386.tar 06-May-2009 04:45 6.7M [FILE] iv_MacOSX.tar 06-May-2009 04:45 6.7M [FILE] iv_MacOSX_i386.tar 06-May-2009 04:45 6.7M [FILE] iv_SunOS_sparc.tar 06-May-2009 04:45 6.7M [FILE] iv_hpux_parisc.tar 06-May-2009 04:44 6.7M [FILE] iv_nt86.exe 06-May-2009 10:11 195k [FILE] iv_ntamd64.exe 06-May-2009 10:11 181k [FILE] iv_ntia64.exe 06-May-2009 04:44 6.2M [FILE] iv_nw.zip 06-May-2009 04:44 5.8M [FILE] iv_w9x.exe 06-May-2009 10:11 195k [DIR] msscaneng/ 06-May-2009 10:12 1k [FILE] testfile.txt 28-Feb-2008 16:01 0k [FILE] version.txt 06-May-2009 08:55 1k

How long has it been like this?  I’m guessing for about a week now given that my eTrust (which normally updates fine about once a day) says it hasn’t updated since 8 days ago.

image