|
|
You're in the
sql server programming
group:Another silly newbie question
sql server programming:
[quoted text, click to view] > Seems a single table with a select > statement is updateable. A multi-table stored procedure is not > updateable. > Is that correct? Welllllll...not exactly. There are certain multi-table views that will be treated as not updatable if an update can introduce anomalies to the base tables. What we do in those cases is to use INSTEAD OF triggers in the views. This is a fairly involved subject, but the good news is that BOL has a very good writeup and examples. Joe De Moor
I am developing a SQL backend for an Access project. If you want a laugh,
read on. Here is a silly question from a newbie. I have two tables. One table determines who can look at what project (tblAvailProject) and the other is the project table (tblProject). I created a test stored procedure for the project screen which is: ALTER PROCEDURE dbo.test2(@UserID nvarchar(20)) AS SELECT dbo.tblProject.ProjectNo AS Expr1, dbo.tblProject.ProjectID FROM dbo.tblAvailProjects LEFT OUTER JOIN dbo.tblProject ON dbo.tblAvailProjects.ProjectNo = dbo.tblProject.ProjectNo WHERE (dbo.tblAvailProjects.UserID = @UserID) The proc runs fine but tblProject is not updateable. I bought 2 books with a combined page count of 1,500 pages on Access and SQL Server but cannot find the answer. Am I missing the obvious? Do I need a number of stored procedures for each form (Insert, Select, Delet, Update)? I thought I could
I'm not sure about your exact question, but I sense perhaps a couple of
issues. Your stored procedure (below) is a SELECT procedure and does not (and will not in its present form) update the table. You will need another method to update the table. It is not at all unusual to have separate stored procedures for SELECT, UPDATE, INSERT, and DELETE operations -often referred to as CRUD procedures (Create, Read, Update, and Delete). Also, when migrating tables (or skills) from Access, one aspect that can cause initial frustration is this: SQL Server requires a way to uniquely identify a row in order to UPDATE or DELETE, and Access seemingly does not. I can't tell, but it may be that your table needs to have a designated primary key or unique index in order to be updateable. -- Arnie Rowland, Ph.D. Westwood Consulting, Inc Most good judgment comes from experience. Most experience comes from bad judgment. - Anonymous You can't help someone get up a hill without getting a little closer to the top yourself. - H. Norman Schwarzkopf [quoted text, click to view] "NevilleT" <NevilleT@discussions.microsoft.com> wrote in message news:38892655-283F-4D14-B471-CB4E351D7454@microsoft.com... >I am developing a SQL backend for an Access project. If you want a laugh, > read on. Here is a silly question from a newbie. > > I have two tables. One table determines who can look at what project > (tblAvailProject) and the other is the project table (tblProject). I > created > a test stored procedure for the project screen which is: > > ALTER PROCEDURE dbo.test2(@UserID nvarchar(20)) > AS SELECT dbo.tblProject.ProjectNo AS Expr1, dbo.tblProject.ProjectID > FROM dbo.tblAvailProjects LEFT OUTER JOIN > dbo.tblProject ON dbo.tblAvailProjects.ProjectNo = > dbo.tblProject.ProjectNo > WHERE (dbo.tblAvailProjects.UserID = @UserID) > > The proc runs fine but tblProject is not updateable. I bought 2 books > with > a combined page count of 1,500 pages on Access and SQL Server but cannot > find > the answer. Am I missing the obvious? Do I need a number of stored > procedures for each form (Insert, Select, Delet, Update)? I thought I > could > update a Select SP.
Hi Arnie
Thanks for the quick response. The primary keys are tblAvailProjects.ProjectNo and tblProject.ProjectNo. I found that if I just used tblProject (which allows everyone to see all records regardless of whether they are permitted) I can update. Seems a single table with a select statement is updateable. A multi-table stored procedure is not updateable. Is that correct? I have to write a proc for each of the four CRUD procedures and run each from a button on the form. [quoted text, click to view] "Arnie Rowland" wrote:
> I'm not sure about your exact question, but I sense perhaps a couple of > issues. > > Your stored procedure (below) is a SELECT procedure and does not (and will > not in its present form) update the table. You will need another method to > update the table. It is not at all unusual to have separate stored > procedures for SELECT, UPDATE, INSERT, and DELETE operations -often referred > to as CRUD procedures (Create, Read, Update, and Delete). > > Also, when migrating tables (or skills) from Access, one aspect that can > cause initial frustration is this: SQL Server requires a way to uniquely > identify a row in order to UPDATE or DELETE, and Access seemingly does not. > I can't tell, but it may be that your table needs to have a designated > primary key or unique index in order to be updateable. > > -- > Arnie Rowland, Ph.D. > Westwood Consulting, Inc > > Most good judgment comes from experience. > Most experience comes from bad judgment. > - Anonymous > > You can't help someone get up a hill without getting a little closer to the > top yourself. > - H. Norman Schwarzkopf > > > "NevilleT" <NevilleT@discussions.microsoft.com> wrote in message > news:38892655-283F-4D14-B471-CB4E351D7454@microsoft.com... > >I am developing a SQL backend for an Access project. If you want a laugh, > > read on. Here is a silly question from a newbie. > > > > I have two tables. One table determines who can look at what project > > (tblAvailProject) and the other is the project table (tblProject). I > > created > > a test stored procedure for the project screen which is: > > > > ALTER PROCEDURE dbo.test2(@UserID nvarchar(20)) > > AS SELECT dbo.tblProject.ProjectNo AS Expr1, dbo.tblProject.ProjectID > > FROM dbo.tblAvailProjects LEFT OUTER JOIN > > dbo.tblProject ON dbo.tblAvailProjects.ProjectNo = > > dbo.tblProject.ProjectNo > > WHERE (dbo.tblAvailProjects.UserID = @UserID) > > > > The proc runs fine but tblProject is not updateable. I bought 2 books > > with > > a combined page count of 1,500 pages on Access and SQL Server but cannot > > find > > the answer. Am I missing the obvious? Do I need a number of stored > > procedures for each form (Insert, Select, Delet, Update)? I thought I > > could > > update a Select SP. > >
NeveilleT
You are running simple SELECT statement, where do you update tblProject table? What is the error message are you getting? [quoted text, click to view] "NevilleT" <NevilleT@discussions.microsoft.com> wrote in message news:38892655-283F-4D14-B471-CB4E351D7454@microsoft.com... >I am developing a SQL backend for an Access project. If you want a laugh, > read on. Here is a silly question from a newbie. > > I have two tables. One table determines who can look at what project > (tblAvailProject) and the other is the project table (tblProject). I > created > a test stored procedure for the project screen which is: > > ALTER PROCEDURE dbo.test2(@UserID nvarchar(20)) > AS SELECT dbo.tblProject.ProjectNo AS Expr1, dbo.tblProject.ProjectID > FROM dbo.tblAvailProjects LEFT OUTER JOIN > dbo.tblProject ON dbo.tblAvailProjects.ProjectNo = > dbo.tblProject.ProjectNo > WHERE (dbo.tblAvailProjects.UserID = @UserID) > > The proc runs fine but tblProject is not updateable. I bought 2 books > with > a combined page count of 1,500 pages on Access and SQL Server but cannot > find > the answer. Am I missing the obvious? Do I need a number of stored > procedures for each form (Insert, Select, Delet, Update)? I thought I > could > update a Select SP.
NevilleT wrote on Tue, 28 Nov 2006 21:50:00 -0800:
[quoted text, click to view] > I am developing a SQL backend for an Access project. If you want a laugh, > read on. Here is a silly question from a newbie. > > I have two tables. One table determines who can look at what project > (tblAvailProject) and the other is the project table (tblProject). I > created a test stored procedure for the project screen which is: > > ALTER PROCEDURE dbo.test2(@UserID nvarchar(20)) > AS SELECT dbo.tblProject.ProjectNo AS Expr1, dbo.tblProject.ProjectID > FROM dbo.tblAvailProjects LEFT OUTER JOIN > dbo.tblProject ON dbo.tblAvailProjects.ProjectNo = > dbo.tblProject.ProjectNo > WHERE (dbo.tblAvailProjects.UserID = @UserID) > > The proc runs fine but tblProject is not updateable. I bought 2 books > with a combined page count of 1,500 pages on Access and SQL Server but > cannot find the answer. Am I missing the obvious? Do I need a number of > stored procedures for each form (Insert, Select, Delet, Update)? I > thought I could update a Select SP. I'm pretty sure it's the LEFT OUTER JOIN that is preventing you from updating tblProject. Dan
Access ADP or MDB?
-- Kevin Hill 3NF Consulting http://www.3nf-inc.com/NewsGroups.htm Real-world stuff I run across with SQL Server: http://kevin3nf.blogspot.com [quoted text, click to view] "NevilleT" <NevilleT@discussions.microsoft.com> wrote in message news:7542CD81-9414-4789-AECB-AC1E9115B7EA@microsoft.com... > Hi Arnie > > Thanks for the quick response. The primary keys are > tblAvailProjects.ProjectNo and tblProject.ProjectNo. I found that if I > just > used tblProject (which allows everyone to see all records regardless of > whether they are permitted) I can update. Seems a single table with a > select > statement is updateable. A multi-table stored procedure is not > updateable. > Is that correct? I have to write a proc for each of the four CRUD > procedures > and run each from a button on the form. > > "Arnie Rowland" wrote: > >> I'm not sure about your exact question, but I sense perhaps a couple of >> issues. >> >> Your stored procedure (below) is a SELECT procedure and does not (and >> will >> not in its present form) update the table. You will need another method >> to >> update the table. It is not at all unusual to have separate stored >> procedures for SELECT, UPDATE, INSERT, and DELETE operations -often >> referred >> to as CRUD procedures (Create, Read, Update, and Delete). >> >> Also, when migrating tables (or skills) from Access, one aspect that can >> cause initial frustration is this: SQL Server requires a way to uniquely >> identify a row in order to UPDATE or DELETE, and Access seemingly does >> not. >> I can't tell, but it may be that your table needs to have a designated >> primary key or unique index in order to be updateable. >> >> -- >> Arnie Rowland, Ph.D. >> Westwood Consulting, Inc >> >> Most good judgment comes from experience. >> Most experience comes from bad judgment. >> - Anonymous >> >> You can't help someone get up a hill without getting a little closer to >> the >> top yourself. >> - H. Norman Schwarzkopf >> >> >> "NevilleT" <NevilleT@discussions.microsoft.com> wrote in message >> news:38892655-283F-4D14-B471-CB4E351D7454@microsoft.com... >> >I am developing a SQL backend for an Access project. If you want a >> >laugh, >> > read on. Here is a silly question from a newbie. >> > >> > I have two tables. One table determines who can look at what project >> > (tblAvailProject) and the other is the project table (tblProject). I >> > created >> > a test stored procedure for the project screen which is: >> > >> > ALTER PROCEDURE dbo.test2(@UserID nvarchar(20)) >> > AS SELECT dbo.tblProject.ProjectNo AS Expr1, >> > dbo.tblProject.ProjectID >> > FROM dbo.tblAvailProjects LEFT OUTER JOIN >> > dbo.tblProject ON dbo.tblAvailProjects.ProjectNo = >> > dbo.tblProject.ProjectNo >> > WHERE (dbo.tblAvailProjects.UserID = @UserID) >> > >> > The proc runs fine but tblProject is not updateable. I bought 2 books >> > with >> > a combined page count of 1,500 pages on Access and SQL Server but >> > cannot >> > find >> > the answer. Am I missing the obvious? Do I need a number of stored >> > procedures for each form (Insert, Select, Delet, Update)? I thought I >> > could >> > update a Select SP. >> >> >>
[quoted text, click to view]
>> One table determines who can look at what project (tblAvailProject) and the other is the project table (tblProject). << Please take that silly "tbl-" prefix off the table names. There is only one data structure in SQL; it is redundant. If the schema models something to do with furniture, it might make sense. Also, why didyou use singular names for sets of data elements? This is not BASIC any more. Please post DDL, so that people do not have to guess what the keys, constraints, Declarative Referential Integrity, data types, etc. in your schema are. Sample data is also a good idea, along with clear specifications. It is very hard to debug code when you do not let us see it. Why do you have both a project id and a project number? Two keys is a bad idea 99.99998% of the time. Based on cleaning up a lot of newbie errors, I would guess that project_id is an IDENTITY column and project_nbr is the real key. Try a schema more like this: CREATE TABLE Projects (project_id INTEGER NOT NULL PRIMARY KEY, project_name CHAR(20) NOT NULL, security_level CHAR(1) NOT NULL -- whatever you need CHECK (security_level BETWEEN 'A' and 'D'), etc.); CREATE TABLE Personnel (emp _id INTEGER NOT NULL PRIMARY KEY, emp_name CHAR(35) NOT NULL, security_level CHAR(1) NOT NULL -- whatever you need CHECK (security_level BETWEEN 'A' and 'D'), etc.); CREATE TABLE ProjectAssignments (project_id INTEGER NOT NULL REFERENCES Projects (project_id) ON UPDATE CASCADE ON DELETE CASCADE, emp_id INTEGER NOT NULL REFERENCES Personnel (emp_id) ON UPDATE CASCADE ON DELETE CASCADE, PRIMARY KEY (project_id, emp_id), etc.); The DRI actions will do a lot of your work for you. Set up VIEWs that include a match on the proper security level. This should allow you to control access for eachj employee involved.
[quoted text, click to view]
> CREATE TABLE Projects > (project_id INTEGER NOT NULL PRIMARY KEY, > project_name CHAR(20) NOT NULL, Why isn't project_name the natural key here? Your schema allows for duplicate project names. How is this SURROGATE KEY project_id calculated? Are you using MAX+1, last number table, or plucking the value out of thin air? Why aren't you using IDENTITY instead of the former two methods because the former two methods create concurrency problems and serialise inserts. If you are using an encoding scheme then where do these magical project_id's come from? Do you have a formula to randomly choose a number or do you have a committee that sits around a table and desides the next number (usually by doing a SELECT for the next available number first...), or do they sit there in the room with a computer and you all start from 1 and issue a SELECT NOT EXISTS until you reach a number that is not used. Why aren't you using an industrial standard for the project_id? Does one exist? [quoted text, click to view] > CREATE TABLE Personnel > (emp _id INTEGER NOT NULL PRIMARY KEY, You keep telling us to use Social Security Numbers for the natural key for people, why haven't you here? Again, you are using a SURROGATE KEY approach to Personnel. Are you using MAX+1, last number table, or plucking the value out of thin air? Why aren't you using IDENTITY instead of the former two methods because the former two methods create concurrency problems and serialise inserts. Why are you so against the IDENTITY property which has NOTHING WHATSOEVER to do with the physical location of rows in storage; given the same order of inserts on any database you get the same values given. Run this on any machine and you get the same IDENTITIES produced.... create database IDENTITYtest go use IDENTITYtest go CREATE TABLE Projects (project_id INTEGER NOT NULL IDENTITY PRIMARY KEY, project_name CHAR(20) NOT NULL, security_level CHAR(1) NOT NULL -- whatever you need CHECK (security_level BETWEEN 'A' and 'D')); go insert Projects( project_name, security_level ) values( 'abc1', 'A' ) insert Projects( project_name, security_level ) values( 'abc2', 'A' ) insert Projects( project_name, security_level ) values( 'abc3', 'A' ) insert Projects( project_name, security_level ) values( 'abc4', 'A' ) insert Projects( project_name, security_level ) values( 'abc5', 'A' ) go select * from Projects order by project_id go use master go drop database IDENTITYTest -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials [quoted text, click to view] "--CELKO--" <jcelko212@earthlink.net> wrote in message news:1164942151.910224.315270@n67g2000cwd.googlegroups.com... >>> One table determines who can look at what project (tblAvailProject) >>> and the other is the project table (tblProject). << > > Please take that silly "tbl-" prefix off the table names. There is > only one data structure in SQL; it is redundant. If the schema models > something to do with furniture, it might make sense. Also, why didyou > use singular names for sets of data elements? This is not BASIC any > more. > > Please post DDL, so that people do not have to guess what the keys, > constraints, Declarative Referential Integrity, data types, etc. in > your schema are. Sample data is also a good idea, along with clear > specifications. It is very hard to debug code when you do not let us > see it. > > Why do you have both a project id and a project number? Two keys is a > bad idea 99.99998% of the time. Based on cleaning up a lot of newbie > errors, I would guess that project_id is an IDENTITY column and > project_nbr is the real key. > > Try a schema more like this: > > CREATE TABLE Projects > (project_id INTEGER NOT NULL PRIMARY KEY, > project_name CHAR(20) NOT NULL, > security_level CHAR(1) NOT NULL -- whatever you need > CHECK (security_level BETWEEN 'A' and 'D'), > etc.); > > CREATE TABLE Personnel > (emp _id INTEGER NOT NULL PRIMARY KEY, > emp_name CHAR(35) NOT NULL, > security_level CHAR(1) NOT NULL -- whatever you need > CHECK (security_level BETWEEN 'A' and 'D'), > etc.); > > CREATE TABLE ProjectAssignments > (project_id INTEGER NOT NULL > REFERENCES Projects (project_id) > ON UPDATE CASCADE > ON DELETE CASCADE, > emp_id INTEGER NOT NULL > REFERENCES Personnel (emp_id) > ON UPDATE CASCADE > ON DELETE CASCADE, > PRIMARY KEY (project_id, emp_id), > etc.); > > The DRI actions will do a lot of your work for you. Set up VIEWs that > include a match on the proper security level. This should allow you to > control access for eachj employee involved. >
[quoted text, click to view]
>>Why isn't project_name the natural key here? Your schema allows for duplicate project names. << Without specs, I cannot know. When I worked for the Georgia DOT, our project names were pretty general, usually a description of the location of the work ("I-20 exit 123"). One location could have several things done to it. [quoted text, click to view] >> How is this SURROGATE KEY project_id calculated? .. If you are using an encoding scheme then where do these magical project_id's come from? << Usually the accounting department. So I would do something that you apparently you would not. I would actually walk down the hall and talk to the people in accounting!! WOW! I bet they have a Chart of Accounts which includes projects in it. The last thing I would be to use an IDENTITY, like some cowboy coder. The failure to walk down the hall did save a few hours or even days of programmer time. Too bad it produced something useless. [quoted text, click to view] >> Why aren't you using an industrial standard for the project_id? Does one exist? << Yes there are several for various industries. For Federal contracts especially. [quoted text, click to view] >> You keep telling us to use Social Security Numbers for the natural key for people, why haven't you here? << Again, without specs, we have no idea how personnel are identified, but I should have used the SSN since it is a legal requirement at some point in the accounting system. My error. That is what happens when you try to show a skeleton on a newsgroup.
[quoted text, click to view]
> You keep telling us to use Social Security Numbers for the natural key for > people, why haven't you here? > Wow. I can't believe that so many are still suggesting this key. I believe that it is irresponsible for consultants to recommend SSN for identification purposes. There has been so much published about this, starting as early as the Privacy Act of 1974. The use of SSN for things not related to wages and benefits, IRS, etc., is not only discouraged, it is not legal many cases. For example, Hawaii had a great time moving away from SSN as a driver's license ID since it is not legal to display it on them, thanks to the 2004 Intelligence Reform and Terrorism Prevention Act. Keep looking... Joe De Moor
[quoted text, click to view]
> Wow. I can't believe that so many are still suggesting this key. I > believe that it is irresponsible for consultants to recommend SSN for > identification purposes. There has been so much published about this, > starting as early as the Privacy Act of 1974. The use of SSN for things > not related to wages and benefits, IRS, etc., is not only discouraged, it > is not legal many cases. For example, Hawaii had a great time moving away > from SSN as a driver's license ID since it is not legal to display it on > them, thanks to the 2004 Intelligence Reform and Terrorism Prevention Act. Something Celko fails to realise..... -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials [quoted text, click to view] "J. M. De Moor" <nospam@nospam.com> wrote in message news:%23X9rzUaFHHA.1248@TK2MSFTNGP02.phx.gbl... >> You keep telling us to use Social Security Numbers for the natural key >> for people, why haven't you here? >> > > Wow. I can't believe that so many are still suggesting this key. I > believe that it is irresponsible for consultants to recommend SSN for > identification purposes. There has been so much published about this, > starting as early as the Privacy Act of 1974. The use of SSN for things > not related to wages and benefits, IRS, etc., is not only discouraged, it > is not legal many cases. For example, Hawaii had a great time moving away > from SSN as a driver's license ID since it is not legal to display it on > them, thanks to the 2004 Intelligence Reform and Terrorism Prevention Act. > > Keep looking... > > Joe De Moor >
[quoted text, click to view]
>> Wow. I can't believe that so many are still suggesting this key. I believe that it is irresponsible for consultants to recommend SSN for identification purposes. << That whole thing is getting really crazy with Homeland "Security" requirements. Some laws require you to verify the SSN before you hire any one and in some cases to ask for and copy the actual SSN card. Other laws say you cannot compel the SSN, but you must report tax data using it. I am one of the few people I know who has his passport, certified birth certificate, and SSN in his desk. Most Americans have never had a passport and lost their other papers decades ago. All we use is a driver's license interally in the States! But every state uses a different encoding. There is a national organization of State DMVs (Department of Motor Vehicles) that was making a move to turn the driver's licenses into a National Identity card and invent a common encoding. I do not know what happened to that effort. [quoted text, click to view] >> For example, Hawaii had a great time moving away from SSN as a driver's license ID since it is not legal to display it on them, thanks to the 2004 Intelligence Reform and Terrorism Prevention Act. << A lot of colleges also got caught on that, too. NYU used to require the students from Canada to get an SSN for a student id, even tho they were not working in the States. Same thing when i went to Georgia Tech mumble-mumble decades ago. [quoted text, click to view] >> Keep looking... << One solution I saw was to build a table of 100 rows which has two columns. The first column is the numbers 00 to 99 and the second is an "encryptor" -- a pattern that tells us how to shift the digits in the SSN based on matching column to the last two digits of the SSN (fastest changing part of number). Example: for each SSN digit, compute MOD ( (ssn_digit + encrypt_digit), 10) for the new code. The advantages are that we retain a CHAR(9) string in the results, so paper forms and screens are the same. Database people tend to forget that the real cost of changing an encoding is in the front ends, not the database side of the house. The good part of this approach is that if you put the same SSN in, you get the same answer out everytime for the same encryptor table. You still need to verify the input before you create a result, of course. But the mathematical Bad News is building a table that maps each SSN to one and only one result. How many tables are possible? Should we allow for the fixed values in the other parts? Etc.?
[quoted text, click to view]
> Some laws require you to verify the SSN before you hire > any one and in some cases to ask for and copy the actual SSN card. I am one who "lost papers" and had first hand experience with all this 15 years ago. [quoted text, click to view] > Other laws say you cannot compel the SSN, but you must report tax data > using it. > Yup. The same company that required my original SSN card (at least) still had a separate employee identification number. Pretty smart actually... I think there is an argument for finding externally verifiable identification for things about which we store information. Sometimes it is hard to find, but it is often there. However, if you go upstream far enough, most identification schemes are arbitrary or surrogate anyway. Just given a number or code of some kind. Now I don't pretend to have anything resembling the DB expertise that finds it way to this board. But I do know one thing. People are not manufactured with lot numbers or UPINs. The only truly unique (natural) identifiers for them are too complex for most of today's data entry systems. Everytime I work with any subject area involving membership, whether financial, trades, insurance or non-profits, I find myself slipstreaming the person ID issue. Just assign a number and a check digit and move on. [quoted text, click to view] > One solution I saw was to build a table of 100 rows which has two > columns. The first column is the numbers 00 to 99 and the second is an > "encryptor" -- a pattern that tells us how to shift the digits in the > SSN based on matching column to the last two digits of the SSN (fastest > changing part of number). Oh my goodness. Let's make it more complicated... I just enjoyed a meeting last week that discussed encoding/encrypting as an option. Ultimately, if you can predict the result, (which in the above example you can as long as 100 values never change) you still technically use the SSN. Joe De Moor
Don't see what you're looking for? Try a search.
|
January 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
April 2008
| home · blog · groups | Questions? Comments? Contact the dn |