SELECT * FROM Questions WHERE Type = 'Stupid'

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > SELECT * FROM Questions WHERE Type = 'Stupid'

«‹›303 »

npe: Oct 15, 2004

Dealing with empty date ranges is actually a huge pain in the rear end with vanilla ANSI SQL. In fact I don't know if there is a way to do it without creating a reference table for your dates. There are often platform specific ways of doing it though, I could help you if you ran Oracle. :v:

In your case you need someone who knows MS SQL. Paging Victor to thread 340343284.

# ? Feb 29, 2008 02:56

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 15:31

<deleted user>

dest posted:

I need a custom Excel SQL query written for my job. The boss wants it, and I don't know a thing about SQL. If I wanted to pay a goon to write it for me, should I post it in here somewhere, or over in SA Mart?

So you need weekly sums per-vendor? That should be pretty easy to do. You might get more help if you post the relevant parts of your SQL schema though.

# ? Feb 29, 2008 03:33

Toanek: Feb 21, 2008; It's a fiesta of personal triumph!

Today I was working on my forum project and while adding in the 'Show My Posts' function I got confused as to how I should format my database query. I initially wanted to sort it so it would return an array of topics ordered by the date of your most recent post in the topic. I eventually decided to sort it by the last post from any user in the topic, but I figured I'd still like to learn how to do it the initial way for well... the learning experience. I can't for the life of me seem to figure it out.

code:

SELECT   topics.id,
         topics.parent_id,
         topics.subject
FROM     topics
         INNER JOIN messages
           ON topics.id = messages.parent_id
WHERE    messages.poster = '" . $user->id . "'
GROUP BY topics.id
ORDER BY messages.date DESC

What I have here orders by the date of your first post in the topic, as opposed to the last.

# ? Feb 29, 2008 04:38

var1ety: Jul 26, 2004

Selecting non-grouped columns in a GROUP BY statement returns inconsistent results.

Take the MAX of your user's post dates and order by the result of this aggregate function.

# ? Feb 29, 2008 04:46

Toanek: Feb 21, 2008; It's a fiesta of personal triumph!

Well, I feel silly for having an amazingly simple solution like that. But hey, it works and I learned something from it. Thanks!

# ? Feb 29, 2008 05:02

Victor: Jun 18, 2004

dest, SQL2000 or SQL2005? If the latter, you can use PIVOT to your advantage. Otherwise, Excel pivot tables would seem to do the trick.

# ? Feb 29, 2008 08:25

Xae: Jan 19, 2005

Toanek posted:

Today I was working on my forum project and while adding in the 'Show My Posts' function I got confused as to how I should format my database query. I initially wanted to sort it so it would return an array of topics ordered by the date of your most recent post in the topic. I eventually decided to sort it by the last post from any user in the topic, but I figured I'd still like to learn how to do it the initial way for well... the learning experience. I can't for the life of me seem to figure it out.
code:
SELECT   topics.id,
         topics.parent_id,
         topics.subject
FROM     topics
         INNER JOIN messages
           ON topics.id = messages.parent_id
WHERE    messages.poster = '" . $user->id . "'
GROUP BY topics.id
ORDER BY messages.date DESC
What I have here orders by the date of your first post in the topic, as opposed to the last.

What RDBMS let you get away with that? Oracle will throw an exception if you try something like that.

# ? Feb 29, 2008 17:17

Victor: Jun 18, 2004

Xae posted:

What RDBMS let you get away with that?

When in doubt with this question, MySQL.

# ? Feb 29, 2008 17:35

dest: May 28, 2003; 9/9/99
Never Forget; Grimey Drawer

I just checked, and it looks like we're running SQL 2000. Here's the query that gives me all of our active vendors. It also filters out all the vendors that have a last purchase date of 1-1-1900. I have no idea why we have a bunch of vendors with that date, but I have to filter them.

code:

SELECT   VENDOR.COMPANYCODE,
         VENDOR.VENDORCODE,
         VENDOR.VENDORNAME,
         VENDOR.YTDPURCHASES,
         VENDOR.LASTPURCHASEDATE,
         VENDOR.ACTIVE
FROM     ABW.DBO.VENDOR VENDOR
WHERE    (VENDOR.COMPANYCODE = 'csp')
         AND (VENDOR.LASTPURCHASEDATE NOT LIKE {TS '1900-01-01 00:00:00'})
         AND (VENDOR.ACTIVE = 1)
ORDER BY VENDOR.VENDORCODE

Here's the query that gives me all the total payments per vendor by week. I run it for every week, and update the date range.

code:

SELECT   APCHECKREGISTERHISTORY.VENDORCODE,
         VENDOR.VENDORNAME,
         SUM(APCHECKREGISTERHISTORY.CHECKAMOUNT)  AS 'TotalPaid'
FROM     ABW.DBO.APCHECKREGISTERHISTORY APCHECKREGISTERHISTORY,
         ABW.DBO.VENDOR VENDOR
WHERE    VENDOR.COMPANYCODE = APCHECKREGISTERHISTORY.COMPANYCODE
         AND VENDOR.VENDORCODE = APCHECKREGISTERHISTORY.VENDORCODE
         AND ((APCHECKREGISTERHISTORY.CHECKDATE BETWEEN '12/29/07' AND '1/4/08'))
GROUP BY APCHECKREGISTERHISTORY.VENDORCODE,VENDOR.VENDORNAME
ORDER BY APCHECKREGISTERHISTORY.VENDORCODE

I run the first query, it gives me all the updated vendors, in case any new ones were added during the week. I output the results to column A in excel. I run the second query, once for each week, output it to a separate excel sheet, then use Merge Tables Wizard, to match the appropriate payments to the appropriate vendors, then sum the columns.

# ? Feb 29, 2008 17:41

Xae: Jan 19, 2005

Victor posted:

When in doubt with this question, MySQL.

Well, there is another reason to hate the drat thing.

# ? Feb 29, 2008 17:54

bitprophet: Jul 22, 2004; Taco Defender

Xae posted:

Well, there is another reason to hate the drat thing.

You don't understand: a blatant disregard for doing things correctly, coupled with being way too lenient about accepted input, is what makes MySQL so easy and is the key to its popularity. And remember, popular = good!

:sigh:

# ? Feb 29, 2008 19:53

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

bitprophet posted:

You don't understand: a blatant disregard for doing things correctly, coupled with being way too lenient about accepted input, is what makes MySQL so easy and is the key to its popularity. And remember, popular = good!

What's a better free alternative?

# ? Feb 29, 2008 20:25

brae: Feb 2, 2006

fletcher posted:

What's a better free alternative?

Postgres. Many people additionally consider it to be "freer" (speech-wise, not beer-wise) than MySQL since it has BSD licensing and because its development isn't controlled by a single, private corporation.

# ? Feb 29, 2008 20:34

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

brae posted:

Postgres. Many people additionally consider it to be "freer" (speech-wise, not beer-wise) than MySQL since it has BSD licensing and because its development isn't controlled by a single, private corporation.

What makes it better? Why should I consider switching to it?

# ? Feb 29, 2008 20:47

brae: Feb 2, 2006

fletcher posted:

What makes it better? Why should I consider switching to it?

Better is subjective depending on what you want your RDBMS to do. All you have to do is google "postgres vs mysql" and you will find many, many comparisons. Then you can be informed and make up your own mind as to what is the better solution for what you want to do.

# ? Feb 29, 2008 21:12

bitprophet: Jul 22, 2004; Taco Defender

brae posted:

Postgres.

brae posted:

Better is subjective depending on what you want your RDBMS to do. All you have to do is google "postgres vs mysql" and you will find many, many comparisons. Then you can be informed and make up your own mind as to what is the better solution for what you want to do.

QFT.

In my own experience - I've used both to an intermediate level both from a developer and sysadmin standpoint - Postgres just feels more mature, streamlined and sensible, versus MySQL feeling, well, like the PHP of databases.

But, like brae said, make up your own mind - Google a bit, and if that doesn't give you anything that makes sense, then come back here and I'm sure we'd be glad to give you ~~a flamewar~~ some insight

# ? Feb 29, 2008 23:25

var1ety: Jul 26, 2004

Oracle 10G XE is free, with the following limitations:

4GB user data
1GB RAM
1 CPU

http://www.oracle.com/technology/products/database/xe/index.html

# ? Feb 29, 2008 23:54

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

var1ety posted:

Oracle 10G XE is free, with the following limitations:

4GB user data
1GB RAM
1 CPU

http://www.oracle.com/technology/products/database/xe/index.html

Interesting. Since my app is written with PDO, and they have an Oracle driver, does that mean I could drop this in a try it pretty easily? Or trying out postgres?

fletcher fucked around with this message at 00:18 on Mar 1, 2008

# ? Mar 1, 2008 00:03

Xae: Jan 19, 2005

bitprophet posted:

QFT.

In my own experience - I've used both to an intermediate level both from a developer and sysadmin standpoint - Postgres just feels more mature, streamlined and sensible, versus MySQL feeling, well, like the PHP of databases.

But, like brae said, make up your own mind - Google a bit, and if that doesn't give you anything that makes sense, then come back here and I'm sure we'd be glad to give you ~~a flamewar~~ some insight

A while ago I went and thought of the reasons why MySQL is better than Postgres. I couldn't think of a single one. Postgres is more secure, more stable, and faster. What? Faster? Yes, when it matters. MySQL gives you back that basic query when there is 0 load a split second faster than Postgres, but when the machine is under a heavy load MySQL shits it self.

# ? Mar 1, 2008 00:09

brae: Feb 2, 2006

Xae posted:

A while ago I went and thought of the reasons why MySQL is better than Postgres. I couldn't think of a single one. Postgres is more secure, more stable, and faster. What? Faster? Yes, when it matters. MySQL gives you back that basic query when there is 0 load a split second faster than Postgres, but when the machine is under a heavy load MySQL shits it self.

I don't know. Several companies have scaled in a big way using MySQL (Yahoo) and carefully choosing your engine type per-table in MySQL can help with scaling because you get a little more fine grained control over locking mechanisms. My company uses MySQL and we've found it to be scaleable. Granted, we haven't done a side-by-side with Postgres, but it's certainly fast enough and for certain optimized queries it is very, very fast even under heavy load.

But I would agree with bitprophet - on some of the more enterprise-y stuff like stored functions and procedures and replication, well, they work with MySQL, but there are a bunch of caveats (for example, stored procedures can't use result sets generated by other stored procedures, at least in the version of 5.0 we're using, and we recently had to upgrade from an earlier 5.0.x release because there were some nasty replication bugs with stored procedures in the version we were on). The same features feel a lot more robust in Postgres - I mean, MySQL only even got stored procedures in version 5. So, we've gotten this stuff to work in MySQL but it feels a little fragile sometimes. Also, MySQL will let you be sloppier in your SQL syntax (see above, selecting a non-aggregate column value from an aggregate query, what the gently caress) and so, at least in my experience, it is easier to write non-portable SQL in it.

# ? Mar 1, 2008 03:26

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

I've been using Postgres for the last 6-7 years, and I can't fault it. It's extremely robust, it's fully-featured, and the documentation is excellent. I can't compare performance but all the benchmarks I've seen put it equal to (if not better than) MySQL. My mind boggled when I found out that MySQL only relatively recently introduced transactions.

There may be certain situations where MySQL is better, but I think most people would be very happy with Postgres.

# ? Mar 1, 2008 04:15

Xae: Jan 19, 2005

brae posted:

I don't know. Several companies have scaled in a big way using MySQL (Yahoo) and carefully choosing your engine type per-table in MySQL can help with scaling because you get a little more fine grained control over locking mechanisms. My company uses MySQL and we've found it to be scaleable. Granted, we haven't done a side-by-side with Postgres, but it's certainly fast enough and for certain optimized queries it is very, very fast even under heavy load.

But I would agree with bitprophet - on some of the more enterprise-y stuff like stored functions and procedures and replication, well, they work with MySQL, but there are a bunch of caveats (for example, stored procedures can't use result sets generated by other stored procedures, at least in the version of 5.0 we're using, and we recently had to upgrade from an earlier 5.0.x release because there were some nasty replication bugs with stored procedures in the version we were on). The same features feel a lot more robust in Postgres - I mean, MySQL only even got stored procedures in version 5. So, we've gotten this stuff to work in MySQL but it feels a little fragile sometimes. Also, MySQL will let you be sloppier in your SQL syntax (see above, selecting a non-aggregate column value from an aggregate query, what the gently caress) and so, at least in my experience, it is easier to write non-portable SQL in it.

http://tweakers.net/reviews/657/5/database-test-dual-intel-xeon-5160-pagina-5.html

The tweakers benchmarks are pretty enlightening. In particular on page 6 you can see how badly MySQL just curls into a ball and cries for mommy on a Niagara (SUN) chip. You also see how quickly MySQL hits the limit of its engine and the requests per second start to decline as concurrency increases, where as Postgres holds stable longer.

MySQL seems to be popular because it is popular. Things are written for it, because it lets you be sloppy, so people run it.

# ? Mar 1, 2008 16:11

MORE CURLY FRIES: Apr 8, 2004

I've got an SQL wonderingness:

I've got two tables, staticApts and dynamicApts.

Static has the following columns:

day, time, comment, details, clientID, staffID

dynamic has the following columns:

date, time, comment, details, clientID, staffID

Static appointments happen every week, so they are referenced by day name and time.

Dynamic appointments happen once, so are referenced by date and time.

Static appointments is a full table with empty cells (well, comment, client and details are blank), where the data is updated based on user input, blank cells indicate that the slot is free.

Dynamic appointments only exist when someone makes one, if the appointment is cancelled then the row is deleted, or if another one is being made over it the row is updated with the new info.

I want a page which gets the appointments for a given user today, and only if they have an appointment. I believe I can do a CREATE VIEW and then only pull rows that have staticApts.comment <> " " or something, but I'm not sure.

The other way would be to create nested if statements and then query individual rows, which is not desirable because that's 32 queries (or something like that) per person per page load.

Essentially:

Is it possible to use the CREATE VIEW, and if so how would I join the tables? staticApts has day as a string and dynamicApts has date as a datetime. There are checks to make sure that an appointment can't exist in the same time slot for either the same staff or the same client, so time could be used to join them I think.

I've been having a think about it but haven't been able to actually work on it, and I won't be for another day or two, but I was hoping that someone could either reinforce or correct my idea before I attempt it and break a load of things.

# ? Mar 2, 2008 21:27

Gumbercules: Jan 12, 2004; These aren't my lamps. These have feet.

Gumbercules posted:

So you want a view which represents every appointment today?

Could you just use a union here?

code:

CREATE VIEW appointments_today
AS
  (SELECT time,
          comment,
          details,
          clientId,
          StaffID
   FROM   staticApts
   WHERE  staticApts.day = DAY_NAME(CURRENT_TIMESTAMP)
   UNION 
   SELECT time,
          comment,
          details,
          clientId,
          StaffID
   FROM   dynamicApts
   WHERE  dynamicApts.date = DATE(CURRENT_TIMESTAMP))

SELECT * FROM appointments_today WHERE clientID = "bob"

It seems like that could get you what you want.

I wasn't sure if a UNION would do what I want. If it does then that's great, cheers!

# ? Mar 3, 2008 03:38

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Great info about postgres guys, thanks. If I was going to try something new should I go postgres or oracle 10g? I don't think I will be going beyond there computer limitations any time soon.

# ? Mar 3, 2008 06:02

Xae: Jan 19, 2005

fletcher posted:

Great info about postgres guys, thanks. If I was going to try something new should I go postgres or oracle 10g? I don't think I will be going beyond there computer limitations any time soon.

I would go with Oracle. It defiantly has more "quirks" to familiarize your self with, and it has broader commercial use as well.

# ? Mar 3, 2008 13:41

var1ety: Jul 26, 2004

fletcher posted:

Great info about postgres guys, thanks. If I was going to try something new should I go postgres or oracle 10g? I don't think I will be going beyond there computer limitations any time soon.

I would use Oracle 10g XE or Microsoft SQL Server XE if I was learning something new. They're both free and mature, with Microsoft SQL Server XE having the advantage of integrating with Visual Studio Express out of the box. My preference is Oracle.

I believe that PostgreSQL is still lacking analytic functions with windowing, a feature I would have a very hard time living without.

# ? Mar 3, 2008 16:05

ninjoatse.cx: Apr 9, 2005; Fun Shoe

Why don't I want to store passwords using an md5() or SHA1() hash? What's insecure about them that makes everyone suggest going elsewhere?

# ? Mar 5, 2008 03:18

noonches: Dec 5, 2005; It represents my lifestyle and stratus as a street savy irreverent youth, who lives large, and yet hungers for the next level in life.

UltraRed posted:

Why don't I want to store passwords using an md5() or SHA1() hash? What's insecure about them that makes everyone suggest going elsewhere?

They can be cracked, that's what makes them insecure. By adding salt you can make it alot more secure tho.

# ? Mar 5, 2008 03:51

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

UltraRed posted:

Why don't I want to store passwords using an md5() or SHA1() hash? What's insecure about them that makes everyone suggest going elsewhere?

It's probably fine to use md5 or sha1, but salt the passwords first to help prevent against rainbow table attacks.

# ? Mar 5, 2008 03:55

ninjoatse.cx: Apr 9, 2005; Fun Shoe

noonches posted:

They can be cracked, that's what makes them insecure. By adding salt you can make it alot more secure tho.

Isn't that true for all widely-distributed hashes? There's nothing specific about those two that make them particularly vulnerable compared to other widely distributed (no-salted) hashes, is there?

# ? Mar 5, 2008 05:08

Victor: Jun 18, 2004

md5 is fairly fast to compute, which is bad for password hashing. some more info

# ? Mar 5, 2008 05:59

noonches: Dec 5, 2005; It represents my lifestyle and stratus as a street savy irreverent youth, who lives large, and yet hungers for the next level in life.

Yeah, as far as I know, if you need a hash to generate the same output every time given a specific input, then it can be cracked using lookup tables. Of course salting a hash is not a function of the hash itself to make it more secure, so that kind of means any hash can be cracked given time and effort put into it.

# ? Mar 5, 2008 06:03

chocojosh: Jun 9, 2007; D00D.

Yes, but you can add a 25 character salt. This way, even if your user enters a password of 8 characters, the actual password is 33 characters. That's going to take much more time to crack than an 8 character password.

Also, adding a salt makes it much harder for someone to figure out what type of hashing you're using. There are certain popular passwords (e.g. "password"). If someone on your system uses that password and it is unsalted, it is very easy to tell which hashing scheme is used (just analyze a table of different hashing schemes for the value "password").

# ? Mar 5, 2008 14:40

Uziel: Jun 28, 2004; Ask me about losing 200lbs, and becoming the Viking God of W&W.

I have a table that contains package, service codes and charges per service. I need to total the charges by account number and I cannot figure out how to do this. This is specific to Access, as the data was provided to me in Access.

This is a sample of what I have:

I edited out actual account information, and only included a small subset, but I basically need to query this table, and show how the total charges per that account number. Keep in mind that there are going to be hundreds of account numbers, with multiple charges per account number.

Example of the Output I'd need from the query:
Account Number | Total
8076123456789000 | 77.94

77.94 is the total amount of charges associated with account number 8076123456789000

Any ideas?

# ? Mar 5, 2008 17:51

noonches: Dec 5, 2005; It represents my lifestyle and stratus as a street savy irreverent youth, who lives large, and yet hungers for the next level in life.

Use the SUM() function on the charge and group by the account number.

# ? Mar 5, 2008 18:00

Lancer383: Aug 15, 2007; Say what you want about the tenants of national socialism, Dude, at least it was an ethos.

I have an Oracle-specific question on a colleague's new "strategy" for SQL "tuning." According to her, using a "somevalue IN ('a', 'b', 'c')" slows down the query's speed (which I believe it really only the case when somevalue is a key field), and the following is her way to speed up queries:

quote:

I still haven�t had much time to test this in the Oracle environment, but I remembered a trick I used in Informix to make a query run faster<snip>...

Basically instead of :

And controlled_group_status in (�A�, �T�, �R�, �D�)

(which causes the query to read the table four times searching for one of those values)

I would use:

And decode(controlled_group_status,�A�,1,�T�,1,�R�,1,�D�,1,0)=1

which only requires one read of the table to evaluate that line. It temporarily assigns every row in that table a value (in this case, 1 if I included it in my decode selection, or a default of zero if I didn�t list the value in my argument) and returns the row if it equals 1 (the values I explicitly listed and assigned a value to).

I know this format works in Oracle as I was able to play with it for a few minutes one day, and it is faster than the IN function, but I haven�t had a chance to determine whether or not it is quicker than the current method of replacing IN statements:

And cg_status = �A� or
Cg_status = �T�.... etc

Any truth to what she is suggesting? It doesn't seem right to me, but I can't put my finger on why. I've found that with many of that office's queries, speed issues tend to be an issue with not using the table indexes in joins, and an obscene use of subqueries and DISTINCTs.

# ? Mar 5, 2008 19:34

npe: Oct 15, 2004

Lancer383 posted:

Any truth to what she is suggesting? It doesn't seem right to me, but I can't put my finger on why. I've found that with many of that office's queries, speed issues tend to be an issue with not using the table indexes in joins, and an obscene use of subqueries and DISTINCTs.

Maybe it depends on something wonky you have going on. On an indexed column it is actually slower for me:

code:

SQL> select jobid from jobs where jobid in (31759, 31758, 31757);

     JOBID
----------
     31757
     31758
     31759


Execution Plan
----------------------------------------------------------

------------------------------------------------------------------
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)|
------------------------------------------------------------------
|   0 | SELECT STATEMENT  |         |     3 |    15 |     2   (0)|
|   1 |  INLIST ITERATOR  |         |       |       |            |
|[b]*  2 |   INDEX RANGE SCAN| JOBS_PK |     3 |    15 |     2   (0)[/b]|
------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("JOBID"=31757 OR "JOBID"=31758 OR "JOBID"=31759)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          [b]7  consistent gets[/b]
          0  physical reads
          0  redo size
        356  bytes sent via SQL*Net to client
        332  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          3  rows processed

code:

SQL> select jobid from jobs where decode(jobid,31759, 1, 31758, 1, 31757, 1, 0) = 1;

     JOBID
----------
     31757
     31758
     31759


Execution Plan
----------------------------------------------------------

---------------------------------------------------------------------
| Id  | Operation            | Name    | Rows  | Bytes | Cost (%CPU)|
---------------------------------------------------------------------
|   0 | SELECT STATEMENT     |         |   184 |   920 |    10   (0)|
|[b]*  1 |  INDEX FAST FULL SCAN| JOBS_PK |   184 |   920 |    10   (0)[/b]|
---------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(DECODE("JOBID",31759,1,31758,1,31757,1,0)=1)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         [b]48  consistent gets[/b]
          0  physical reads
          0  redo size
        356  bytes sent via SQL*Net to client
        332  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          3  rows processed

# ? Mar 5, 2008 20:12

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 15:31

Lancer383: Aug 15, 2007; Say what you want about the tenants of national socialism, Dude, at least it was an ethos.

yaoi prophet posted:

<snipped out yaoi's sweet analysis>

Thanks for checking this out -- I'm fairly sure that she is delirious -- could you give it a try on a non-indexed column and see if you have similar results? I would do it on my own, but a Plan_Table table isn't set up on our Oracle DBs, and if there's a way to see an explanation plan without a plan_table, I don't know how to do it.

# ? Mar 5, 2008 20:33

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > SELECT * FROM Questions WHERE Type = 'Stupid'

«‹›303 »

dest posted:

code:

Toanek posted:

code:

Xae posted:

code:

code:

Victor posted:

Xae posted:

bitprophet posted:

fletcher posted:

brae posted:

fletcher posted:

brae posted:

brae posted:

var1ety posted:

bitprophet posted:

Xae posted:

brae posted:

MORE CURLY FRIES posted:

code:

Gumbercules posted:

code:

fletcher posted:

fletcher posted:

UltraRed posted:

UltraRed posted:

noonches posted:

quote:

Lancer383 posted:

code:

code:

yaoi prophet posted: