June 15, 2014 at 2:14 pm
Koen Verbeeck (6/14/2014)
Typically you break a datetime into a date part and a time part and store it in two dimensions.
This allows you to solve analytical questions on the date part (with attributes stored in the date dimensions), such as influences of weekdays, holidays, seasonality and so on. In the time dimension, you can store attributes such as opening hours, part of the day (morning, midday, afternoon, evening, night) and so on. So the seperation is done for a reason 🙂
If you need the actual datetime for some reason (and you don't want to join two times), you can indeed store it along in the fact table as a degenerate dimension.
Plus about a million
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
June 15, 2014 at 2:23 pm
Koen Verbeeck (6/14/2014)
andrew gothard (6/13/2014)
" store the dates as integers, like 20140612, and then join to a 'Date' table with this 'key' to get a real date field" - this still is a strong design smell, but if you're using a DateDim (or calendar table) in a DataWarehouse (or other) environment, ish. I think storing the integer format date, rather than an identity for the join is plain stupid. But a link into a DateDim / Calendar table is a lot less hassle and a bloody sight easier if you want to know working days, financial weeks, months, years.What is the difference between having an integer key that has the value 12575 or the value 20140513?
The first one is just a sequence, while the second one is a sequence as well but with some gaps once in a while.
The second one helps debugging (no extra join needed when you quickly want to check something) and also helps with partitioning if necessary.
Why is the second one plain stupid? I'd like to be enlightened 🙂
Badly phrased, sorry. In a column that should be a date, it's plain stupid (if you do that in your Order Taken timestamp column in your SOP system, you're an imbecile and your keyboard should be confiscated) - in a DateDim, ok-ish, but personally I'd prefer an identity. If it looks like a date, someone's going to do something stupid with it at some point.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
June 16, 2014 at 7:32 am
Evil Kraig F (6/13/2014)
Offhand, even in my warehouses, I never really saw a significant value in storing the date as a four byte int instead of the 8 byte datetime. Yes, I have used many a calendar table, and just keyed it off the datetime field. With a constraint to make sure the value equaled itself without time no 'bad' data would become included in either the fact or the dimension, and it allowed us to skip, completely, moving to the dimension table for date range based information that didn't require the subdata and allowed for more effective indexing against the fact.I'm sorry, but I can't agree with the idea of surrogate keying a date. There's too much value to bringing the dimension in later in the execution plan to bother, especially if you're running ROLAP cubes.
I think that they set it up to be used for cubes. To have one 'Date' table and every place you would have had a date in a table it is a 'date ID' to point ot this 'Date' table. I was looking at one table and it has at least 4 'date ID' fields, that means 4 joins just to get the real date values. This just seems to be creating a lot of extra joins for each table. Like I said before I think it may be fast now for the amount of data they have loaded, only about 4 or 5 years of our data. But I would think this is only going to get slower the more data that is loaded.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
June 16, 2014 at 7:44 am
andrew gothard (6/15/2014)
Koen Verbeeck (6/14/2014)
Badly phrased, sorry. In a column that should be a date, it's plain stupid (if you do that in your Order Taken timestamp column in your SOP system, you're an imbecile and your keyboard should be confiscated) - in a DateDim, ok-ish, but personally I'd prefer an identity. If it looks like a date, someone's going to do something stupid with it at some point.
That's what I 'm afraid someone outside of IS is going to look at that 'date ID' field and say, 'Well that's the date.' and try and do "something stupid with it".
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
June 16, 2014 at 9:23 am
Koen Verbeeck (6/14/2014)
Michael Valentine Jones (6/13/2014)
Something no one has mentioned is DATETIME in the fact table for situations where it may be important. I have seen people break date and time into different columns. That just makes for horrible coding for queries when you need to select data for a DATETIME range. Example: from 10:00 am on the second day of the month through 6:00 pm yesterday. I believe Kimball called a dimensional column like this with no dimension table a "degenerate" dimension. Of course, you could also have Date and time of day dimensions in addition to the "degenerate" datetime dimension.Typically you break a datetime into a date part and a time part and store it in two dimensions.
This allows you to solve analytical questions on the date part (with attributes stored in the date dimensions), such as influences of weekdays, holidays, seasonality and so on. In the time dimension, you can store attributes such as opening hours, part of the day (morning, midday, afternoon, evening, night) and so on. So the seperation is done for a reason 🙂
If you need the actual datetime for some reason (and you don't want to join two times), you can indeed store it along in the fact table as a degenerate dimension.
Yes, of course you can have the Date and Time dimensions, which is why I mentioned them in my post, and didn't imply that you would not want them.
The point I was making was that sometimes you want the datetime together, particularly for selection of datetime ranges. Notice the complexity of the second query without the datetime dimension when only the Date and Time dimensions are available.
-- With degenerate datetime dimension
select
*
from
SalesFact sf
where
SaleDatetime >= '2014-06-02 10:00:00' and
SaleDatetime < '2014-06-16 18:00:00'
-- Without degenerate datetime dimension
select
*
from
SalesFact sf
inner join
DateDim dd
on dd.Date = sf.Date
inner join
TimeDim td
on td.Time = sf.Time
where
dd.Date between '2014-06-02' and '2014-06-16'
and
case
when dd.Date = '2014-06-02' and td.Time < '10:00:00'
then then 0
when dd.Date = '2014-06-16' and td.Time >= '18:00:00'
then then 0
else 1 end = 1
June 16, 2014 at 10:44 am
Michael Valentine Jones (6/16/2014)
Koen Verbeeck (6/14/2014)
Michael Valentine Jones (6/13/2014)
Something no one has mentioned is DATETIME in the fact table for situations where it may be important. I have seen people break date and time into different columns. That just makes for horrible coding for queries when you need to select data for a DATETIME range. Example: from 10:00 am on the second day of the month through 6:00 pm yesterday. I believe Kimball called a dimensional column like this with no dimension table a "degenerate" dimension. Of course, you could also have Date and time of day dimensions in addition to the "degenerate" datetime dimension.Typically you break a datetime into a date part and a time part and store it in two dimensions.
This allows you to solve analytical questions on the date part (with attributes stored in the date dimensions), such as influences of weekdays, holidays, seasonality and so on. In the time dimension, you can store attributes such as opening hours, part of the day (morning, midday, afternoon, evening, night) and so on. So the seperation is done for a reason 🙂
If you need the actual datetime for some reason (and you don't want to join two times), you can indeed store it along in the fact table as a degenerate dimension.
Yes, of course you can have the Date and Time dimensions, which is why I mentioned them in my post, and didn't imply that you would not want them.
The point I was making was that sometimes you want the datetime together, particularly for selection of datetime ranges. Notice the complexity of the second query without the datetime dimension when only the Date and Time dimensions are available.
-- With degenerate datetime dimension
select
*
from
SalesFact sf
where
SaleDatetime >= '2014-06-02 10:00:00' and
SaleDatetime < '2014-06-16 18:00:00'
-- Without degenerate datetime dimension
select
*
from
SalesFact sf
inner join
DateDim dd
on dd.Date = sf.Date
inner join
TimeDim td
on td.Time = sf.Time
where
dd.Date between '2014-06-02' and '2014-06-16'
and
case
when dd.Date = '2014-06-02' and td.Time < '10:00:00'
then then 0
when dd.Date = '2014-06-16' and td.Time >= '18:00:00'
then then 0
else 1 end = 1
You are 100% correct.
However, and this may be colored by my experience, I believe such queries are rather uncommon in data warehouses where the typical query is more analytical in nature. Correct me if I'm wrong 😀
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
June 16, 2014 at 5:11 pm
Koen Verbeeck (6/16/2014)
Michael Valentine Jones (6/16/2014)
Koen Verbeeck (6/14/2014)
Michael Valentine Jones (6/13/2014)
Something no one has mentioned is DATETIME in the fact table for situations where it may be important. I have seen people break date and time into different columns. That just makes for horrible coding for queries when you need to select data for a DATETIME range. Example: from 10:00 am on the second day of the month through 6:00 pm yesterday. I believe Kimball called a dimensional column like this with no dimension table a "degenerate" dimension. Of course, you could also have Date and time of day dimensions in addition to the "degenerate" datetime dimension.Typically you break a datetime into a date part and a time part and store it in two dimensions.
This allows you to solve analytical questions on the date part (with attributes stored in the date dimensions), such as influences of weekdays, holidays, seasonality and so on. In the time dimension, you can store attributes such as opening hours, part of the day (morning, midday, afternoon, evening, night) and so on. So the seperation is done for a reason 🙂
If you need the actual datetime for some reason (and you don't want to join two times), you can indeed store it along in the fact table as a degenerate dimension.
Yes, of course you can have the Date and Time dimensions, which is why I mentioned them in my post, and didn't imply that you would not want them.
The point I was making was that sometimes you want the datetime together, particularly for selection of datetime ranges. Notice the complexity of the second query without the datetime dimension when only the Date and Time dimensions are available.
-- With degenerate datetime dimension
select
*
from
SalesFact sf
where
SaleDatetime >= '2014-06-02 10:00:00' and
SaleDatetime < '2014-06-16 18:00:00'
-- Without degenerate datetime dimension
select
*
from
SalesFact sf
inner join
DateDim dd
on dd.Date = sf.Date
inner join
TimeDim td
on td.Time = sf.Time
where
dd.Date between '2014-06-02' and '2014-06-16'
and
case
when dd.Date = '2014-06-02' and td.Time < '10:00:00'
then then 0
when dd.Date = '2014-06-16' and td.Time >= '18:00:00'
then then 0
else 1 end = 1
You are 100% correct.
However, and this may be colored by my experience, I believe such queries are rather uncommon in data warehouses where the typical query is more analytical in nature. Correct me if I'm wrong 😀
As always, it depends on the application.
If your warehouse shades closer to an operational data store where you may be looking for particular items or exceptions, then you would be more likely to need the datetime dimension.
June 18, 2014 at 5:06 am
below86 (6/16/2014)
andrew gothard (6/15/2014)
Koen Verbeeck (6/14/2014)
Badly phrased, sorry. In a column that should be a date, it's plain stupid (if you do that in your Order Taken timestamp column in your SOP system, you're an imbecile and your keyboard should be confiscated) - in a DateDim, ok-ish, but personally I'd prefer an identity. If it looks like a date, someone's going to do something stupid with it at some point.
That's what I 'm afraid someone outside of IS is going to look at that 'date ID' field and say, 'Well that's the date.' and try and do "something stupid with it".
Outside IS?
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
June 18, 2014 at 7:19 am
andrew gothard (6/18/2014)
below86 (6/16/2014)
andrew gothard (6/15/2014)
Koen Verbeeck (6/14/2014)
Badly phrased, sorry. In a column that should be a date, it's plain stupid (if you do that in your Order Taken timestamp column in your SOP system, you're an imbecile and your keyboard should be confiscated) - in a DateDim, ok-ish, but personally I'd prefer an identity. If it looks like a date, someone's going to do something stupid with it at some point.
That's what I 'm afraid someone outside of IS is going to look at that 'date ID' field and say, 'Well that's the date.' and try and do "something stupid with it".
Outside IS?
Yes, we have certain departments that have a few people that know just enough SQL to write some queries, most of the ones I've seen would be perfect examples for this post, on what not to do.:w00t: We currently don't have enough programmers(developers) to fill all the request from everyone, so some areas have found people in their departments that can run queries to answer some questions. The amount of manual work some of these people go thru is amazing. Spending days to put together reports that if we had the time we could automate and have it built in minutes. But what can you do, only so many hours in a day. 🙂
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
June 18, 2014 at 7:29 am
below86 (6/18/2014)
andrew gothard (6/18/2014)
below86 (6/16/2014)
andrew gothard (6/15/2014)
Koen Verbeeck (6/14/2014)
Badly phrased, sorry. In a column that should be a date, it's plain stupid (if you do that in your Order Taken timestamp column in your SOP system, you're an imbecile and your keyboard should be confiscated) - in a DateDim, ok-ish, but personally I'd prefer an identity. If it looks like a date, someone's going to do something stupid with it at some point.
That's what I 'm afraid someone outside of IS is going to look at that 'date ID' field and say, 'Well that's the date.' and try and do "something stupid with it".
Outside IS?
Yes, we have certain departments that have a few people that know just enough SQL to write some queries, most of the ones I've seen would be perfect examples for this post, on what not to do.:w00t: We currently don't have enough programmers(developers) to fill all the request from everyone, so some areas have found people in their departments that can run queries to answer some questions. The amount of manual work some of these people go thru is amazing. Spending days to put together reports that if we had the time we could automate and have it built in minutes. But what can you do, only so many hours in a day. 🙂
I once worked for a company with a similar problem. The solution was pretty simple... I spent some time with the users to find out what kind of reports they were typically interested in and then held some Lunch'n'Learn classes that taught them all about Date functions, Crosstabs, how to write the right kind of dynamic SQL for the CrossTabs, how to do pre-aggregation for wicked performance, and how to do a little Divide'n'Conquer querying for even better performance. The classes each had a handout associated with it that became a part of a "book" in Word complete with a table of contents and a bit of an index and a glossary. The ROI for the time I spent was huge and the users got very smart about their repointing queries very quickly. It was absolutely amazing at how "hungry" and appreciative they were for knowledge.
--Jeff Moden
June 18, 2014 at 7:47 am
Jeff Moden (6/18/2014)
below86 (6/18/2014)
andrew gothard (6/18/2014)
below86 (6/16/2014)
andrew gothard (6/15/2014)
Koen Verbeeck (6/14/2014)
Badly phrased, sorry. In a column that should be a date, it's plain stupid (if you do that in your Order Taken timestamp column in your SOP system, you're an imbecile and your keyboard should be confiscated) - in a DateDim, ok-ish, but personally I'd prefer an identity. If it looks like a date, someone's going to do something stupid with it at some point.
That's what I 'm afraid someone outside of IS is going to look at that 'date ID' field and say, 'Well that's the date.' and try and do "something stupid with it".
Outside IS?
Yes, we have certain departments that have a few people that know just enough SQL to write some queries, most of the ones I've seen would be perfect examples for this post, on what not to do.:w00t: We currently don't have enough programmers(developers) to fill all the request from everyone, so some areas have found people in their departments that can run queries to answer some questions. The amount of manual work some of these people go thru is amazing. Spending days to put together reports that if we had the time we could automate and have it built in minutes. But what can you do, only so many hours in a day. 🙂
I once worked for a company with a similar problem. The solution was pretty simple... I spent some time with the users to find out what kind of reports they were typically interested in and then held some Lunch'n'Learn classes that taught them all about Date functions, Crosstabs, how to write the right kind of dynamic SQL for the CrossTabs, how to do pre-aggregation for wicked performance, and how to do a little Divide'n'Conquer querying for even better performance. The classes each had a handout associated with it that became a part of a "book" in Word complete with a table of contents and a bit of an index and a glossary. The ROI for the time I spent was huge and the users got very smart about their repointing queries very quickly. It was absolutely amazing at how "hungry" and appreciative they were for knowledge.
That would be nice to do, and I do know some of them would be very receptive to it. It still comes down to time, my managers giving the OK, and me sacrificing my lunch time.:-) But I can't even get the rest of the developers on my team to try and follow simple formatting of their SQL. I'd like to clean up 'our backyard' before worrying about others. At least some days i feel that way. :hehe:
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
June 18, 2014 at 7:55 am
below86 (6/18/2014)
Jeff Moden (6/18/2014)
below86 (6/18/2014)
andrew gothard (6/18/2014)
below86 (6/16/2014)
andrew gothard (6/15/2014)
Koen Verbeeck (6/14/2014)
Badly phrased, sorry. In a column that should be a date, it's plain stupid (if you do that in your Order Taken timestamp column in your SOP system, you're an imbecile and your keyboard should be confiscated) - in a DateDim, ok-ish, but personally I'd prefer an identity. If it looks like a date, someone's going to do something stupid with it at some point.
That's what I 'm afraid someone outside of IS is going to look at that 'date ID' field and say, 'Well that's the date.' and try and do "something stupid with it".
Outside IS?
Yes, we have certain departments that have a few people that know just enough SQL to write some queries, most of the ones I've seen would be perfect examples for this post, on what not to do.:w00t: We currently don't have enough programmers(developers) to fill all the request from everyone, so some areas have found people in their departments that can run queries to answer some questions. The amount of manual work some of these people go thru is amazing. Spending days to put together reports that if we had the time we could automate and have it built in minutes. But what can you do, only so many hours in a day. 🙂
I once worked for a company with a similar problem. The solution was pretty simple... I spent some time with the users to find out what kind of reports they were typically interested in and then held some Lunch'n'Learn classes that taught them all about Date functions, Crosstabs, how to write the right kind of dynamic SQL for the CrossTabs, how to do pre-aggregation for wicked performance, and how to do a little Divide'n'Conquer querying for even better performance. The classes each had a handout associated with it that became a part of a "book" in Word complete with a table of contents and a bit of an index and a glossary. The ROI for the time I spent was huge and the users got very smart about their repointing queries very quickly. It was absolutely amazing at how "hungry" and appreciative they were for knowledge.
That would be nice to do, and I do know some of them would be very receptive to it. It still comes down to time, my managers giving the OK, and me sacrificing my lunch time.:-) But I can't even get the rest of the developers on my team to try and follow simple formatting of their SQL. I'd like to clean up 'our backyard' before worrying about others. At least some days i feel that way. :hehe:
You might be surprised. Often times people in that position will write some beautifully formatted code. Especially if they are shown code with nice formatting from the beginning. And sacrificing your lunch once a month should be a non-issue. It isn't that frequent and you will gain tons of respect and probably discover that you enjoy it yourself and start looking forward to the next session.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
June 18, 2014 at 8:05 am
Sean Lange (6/18/2014)
below86 (6/18/2014)
Jeff Moden (6/18/2014)
below86 (6/18/2014)
andrew gothard (6/18/2014)
below86 (6/16/2014)
andrew gothard (6/15/2014)
Koen Verbeeck (6/14/2014)
Badly phrased, sorry. In a column that should be a date, it's plain stupid (if you do that in your Order Taken timestamp column in your SOP system, you're an imbecile and your keyboard should be confiscated) - in a DateDim, ok-ish, but personally I'd prefer an identity. If it looks like a date, someone's going to do something stupid with it at some point.
That's what I 'm afraid someone outside of IS is going to look at that 'date ID' field and say, 'Well that's the date.' and try and do "something stupid with it".
Outside IS?
Yes, we have certain departments that have a few people that know just enough SQL to write some queries, most of the ones I've seen would be perfect examples for this post, on what not to do.:w00t: We currently don't have enough programmers(developers) to fill all the request from everyone, so some areas have found people in their departments that can run queries to answer some questions. The amount of manual work some of these people go thru is amazing. Spending days to put together reports that if we had the time we could automate and have it built in minutes. But what can you do, only so many hours in a day. 🙂
I once worked for a company with a similar problem. The solution was pretty simple... I spent some time with the users to find out what kind of reports they were typically interested in and then held some Lunch'n'Learn classes that taught them all about Date functions, Crosstabs, how to write the right kind of dynamic SQL for the CrossTabs, how to do pre-aggregation for wicked performance, and how to do a little Divide'n'Conquer querying for even better performance. The classes each had a handout associated with it that became a part of a "book" in Word complete with a table of contents and a bit of an index and a glossary. The ROI for the time I spent was huge and the users got very smart about their repointing queries very quickly. It was absolutely amazing at how "hungry" and appreciative they were for knowledge.
That would be nice to do, and I do know some of them would be very receptive to it. It still comes down to time, my managers giving the OK, and me sacrificing my lunch time.:-) But I can't even get the rest of the developers on my team to try and follow simple formatting of their SQL. I'd like to clean up 'our backyard' before worrying about others. At least some days i feel that way. :hehe:
You might be surprised. Often times people in that position will write some beautifully formatted code. Especially if they are shown code with nice formatting from the beginning. And sacrificing your lunch once a month should be a non-issue. It isn't that frequent and you will gain tons of respect and probably discover that you enjoy it yourself and start looking forward to the next session.
Thank you Jeff, below86 and Sean for this reminder that this is so very much still on my list of things to do. I find that it takes quite me some time to come up with a scope for a talk that's narrow enough to cover in an hour. I just need to figure out how to do it without 8 or more hours of preparation.
June 18, 2014 at 8:06 am
below86 (6/18/2014)
Jeff Moden (6/18/2014)
below86 (6/18/2014)
andrew gothard (6/18/2014)
below86 (6/16/2014)
andrew gothard (6/15/2014)
Koen Verbeeck (6/14/2014)
Badly phrased, sorry. In a column that should be a date, it's plain stupid (if you do that in your Order Taken timestamp column in your SOP system, you're an imbecile and your keyboard should be confiscated) - in a DateDim, ok-ish, but personally I'd prefer an identity. If it looks like a date, someone's going to do something stupid with it at some point.
That's what I 'm afraid someone outside of IS is going to look at that 'date ID' field and say, 'Well that's the date.' and try and do "something stupid with it".
Outside IS?
Yes, we have certain departments that have a few people that know just enough SQL to write some queries, most of the ones I've seen would be perfect examples for this post, on what not to do.:w00t: We currently don't have enough programmers(developers) to fill all the request from everyone, so some areas have found people in their departments that can run queries to answer some questions. The amount of manual work some of these people go thru is amazing. Spending days to put together reports that if we had the time we could automate and have it built in minutes. But what can you do, only so many hours in a day. 🙂
I once worked for a company with a similar problem. The solution was pretty simple... I spent some time with the users to find out what kind of reports they were typically interested in and then held some Lunch'n'Learn classes that taught them all about Date functions, Crosstabs, how to write the right kind of dynamic SQL for the CrossTabs, how to do pre-aggregation for wicked performance, and how to do a little Divide'n'Conquer querying for even better performance. The classes each had a handout associated with it that became a part of a "book" in Word complete with a table of contents and a bit of an index and a glossary. The ROI for the time I spent was huge and the users got very smart about their repointing queries very quickly. It was absolutely amazing at how "hungry" and appreciative they were for knowledge.
That would be nice to do, and I do know some of them would be very receptive to it. It still comes down to time, my managers giving the OK, and me sacrificing my lunch time.:-) But I can't even get the rest of the developers on my team to try and follow simple formatting of their SQL. I'd like to clean up 'our backyard' before worrying about others. At least some days i feel that way. :hehe:
In order to do that, you're going to have to create a written set of standards, do 100% peer reviews to enforce them, and have Management buy in that no code goes to production until it meets standards. It'll slow things down at first but the long term benefit is that the amount of time spent on rework due to failures or rework due to required changes will plummet to very near zero. I've done this at 3 of the larger companies I've worked for and the end result has always been fantastic.
--Jeff Moden
June 18, 2014 at 8:08 am
Sean Lange (6/18/2014)
You might be surprised. Often times people in that position will write some beautifully formatted code. Especially if they are shown code with nice formatting from the beginning. And sacrificing your lunch once a month should be a non-issue. It isn't that frequent and you will gain tons of respect and probably discover that you enjoy it yourself and start looking forward to the next session.
I do know some have started doing some of the formatting. Only after I had to fix one of their code, I also reformatted it, I just couldn't help myself.:-) But I get real hungry come lunch time. 🙂 I know your right Sean. I'll see if I can muster up enough courage to stand up in front of them to try and teach them the correct techniques.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
Viewing 15 posts - 241 through 255 (of 271 total)
You must be logged in to reply to this topic. Login to reply