|
The answer's in the code. UP in SPACE is where the coder seems to be. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
|
No, this was originaly posted in the C# forum by Mc_Topaz and I copied it here as an example of "why the hell did you do that and then ask why it doesn't work?". Hence the "From our own C# forum" and "What do they teach them" bits.
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.
This message is made of fully recyclable Zeros and Ones
|
|
|
|
|
Andrew Pallant wrote: I am not one to usually say anything about posting in the wrong forum, but you really did this time.
Did you actually read the post? The OP didn't post a programming question at all, he's pointing out a very misguided bit of code posted by someone else.
|
|
|
|
|
I wonder if one can actually press the keys fast enough, without keeping the other one pressed 
Nice one.
Cheers
You have the thought that modern physics just relay on assumptions, that somehow depends on a smile of a cat, which isn’t there.( Albert Einstein)
|
|
|
|
|
LOL - suggest him to save the last pressed key. If the currently pressed key is space und the last key was keyup or vice versa then his condition is fulfilled.
|
|
|
|
|
First, this person seems to be in school and is currently learning programming. Next, this posting IS appropriate for the C# forum.
This person's folly is obviously their lack of paying attention to the precise nature of all pieces of the code (ie. KeyCode cannot equal to different things). They are thinking of the "if" statement as a perverse non-procedural construct, similar to an SQL "select" statement.
However, the imagination displayed here is in the spirit of a real programming concept: bit mask.
|
|
|
|
|
No, his folly was to post the question here.
I don't know if he has ADS or something, but the red warning of not posting programming questions here is hard to overlook.
I always marvel anew at those that don't even spend 0.2 seconds to verify if the place they ask a programming question is even remotely right.
Maybe we should redirect them to some forum about cats next time, it's certainly not a wronger place to ask.
|
|
|
|
|
You might not have seen the post before it was deleted. Why it was? I don't know.
The fellow wrote ABOUT a question in the c# forum (NOT THIS ONE). There were no rules broken on posting procedure.
|
|
|
|
|
Some DB geniuses created this and more.
CREATE TABLE [dbo].[ImportDownload_85_Work](
[ImportFileID] [int] NOT NULL,
[RowID] [int] NOT NULL,
[Data001] [varchar](800) NULL,
[Data002] [varchar](800) NULL,
[Data003] [varchar](800) NULL,
[Data004] [varchar](800) NULL,
[Data005] [varchar](800) NULL,
[Data006] [varchar](800) NULL,
[Data007] [varchar](8000) NULL,
[Data008] [varchar](8000) NULL,
[Data009] [varchar](8000) NULL,
[Data010] [varchar](8000) NULL,
[Data011] [varchar](8000) NULL,
...
[Data195] [varchar](8000) NULL,
[Data196] [varchar](8000) NULL,
[Data197] [varchar](8000) NULL,
[Data198] [varchar](8000) NULL,
[Data199] [varchar](8000) NULL
) ON [PRIMARY]
There are over 100 tables like this on one filegroup and one file! 
Oh yea, the identical copies for each suffixed _Last instead of _Work 
|
|
|
|
|
Great. He plans on storing data in there!?
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
Looks like a temporary holding place some sort of imported data to me.
|
|
|
|
|
it is a database after all...
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
Unfortunately, it is a permanent import repository.
|
|
|
|
|
code looks great, it is obviously a temp data pool from SETI signal recievers ready to be split up and sent out to all those who have the SETI screen saver, processed then sent back, injected into the real tables that have a naming convention, it is only obfuscated here to protect sensitive national security secrets. 
|
|
|
|
|
Generics comes to SQL.
|
|
|
|
|
SELECT NULL FROM Brain Where Engaged = 0
|
|
|
|
|
LOL! I think he omitted that table
GSoC 2009 student for SMW!
---
My little forums: http://code.bn2vs.com
---
70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
|
|
|
|
|
What's not to love... 
|
|
|
|
|
Which Normal Form is that?
|
|
|
|
|
First Imaginary Form
|
|
|
|
|
Must be government work!
Sam
|
|
|
|
|
That looks a lot like the Oracle tables at the company that I used to work at. I really hated having to query that database. You didn't have any clue as to what each field was being used for.
Kelly Herald
Software Developer
|
|
|
|
|
This table design could be used to reduce the size of a database and improve manageability that contains unknown/highly dynamic structures
I will make an assumption (the only one in this post) and say this project deals with loading structures that change frequently. Could be wrong and be looking at a noob's 'work of art'
There are three approaches for highly dynamic structural data:
1. Dynamically create the schema's based on external blue-prints, giving real names to columns. This might not be the best solution for a few subtle reasons which have to do with the degree of knowledge by the end-user's of the database and any planned api's or DAL's. Generating the dynamic schema prior to loading data can be done in two modes: 1. immediately, where new un-generated schemas are encountered and have to be generated on the spot. This presents an obvious problem if you have multiple clients performing the imports for a single database (similar to SETI). Such as, what if two clients encounter the same type of schema that isn't in the database yet, only one schema should be generated. 2. Delayed, where after loading many imports and discovering that some new files failed to match any current dynamic schema, the database user can manually kick off schema generation and then attempt a reload of those files that failed earlier.
2. Contain the all the data into a single table (or a table for each datatype) with four columns (ImportFileId, RowId[original structure's], ParameterName, ParameterValue). This solution gobbles up WAY MORE disk space (more than doubles the space requirement of the solution given above as well as in #1 (In oracle, at least, the remaining columns that are null take up no space.) This is considered serializing the data, also could be called demuxing.
3. Then there is the solution above. The only requirement is that any API must map the ImportFileId to some blue-print of the columns involved. This solution saves much more space than #2 AND has the added benefit of simplicity on the database up-keep side (ie. no schema generation prior to import)
I've been down this road dealing with a database with over 400,000 actual unique fields of data. We actually used option #1 for good reason. So, I wouldn't knock it just because it's different.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
