Usually, narrative and a scribbled semblance of a table isn't enough to fully
understand the structure and nature of your data, or at least not enough to solve your
problem. So that we can spend more time actually working on your query (either solving
an existing syntax or logic problem, or coming up with a way to get the output in your
desired format), it helps if we can create the table on our system, and populate it
with data, with minimal effort. If we have to waste time dreaming up fictitious data
and guessing what you were describing in your word problem, we are likely going to give up.
So, often, you will see us ask for DDL, sample data and
Note that all three of those components are very important. If we can't determine enough
from your initial question, we are going to ask you for the above. If you only give us one
or two out of three, we're going to ask you again to supply all three. If you still can't
be bothered to provide the requested info so that *we* can help *you,* free of charge, we are
likely going to move on to the same thread. And likewise (though I won't speak for everyone
here) if you give us attitude about it, like insinuating we are stupid because obviously
your description of the problem is so simple that a 2-year old would get it.
Think about when you call your doctor or your mechanic. Do you tell them "I don't feel
good" or "it's broke"? What do you think would be their response if you did? They would
tell you to provide enough information so they can help diagnose the problem. That's all
we're asking for.
DDL stands for Data Definition Language, and is often referred to as "Table structure."
This is the CREATE TABLE script that will allow us to reproduce and work against your
table on our own systems.
If you are using SQL Server, you can generate CREATE TABLE scripts from within Query
Analyzer by pressing F8 (Object Browser), expanding the database, expanding User Tables,
right-clicking the table in question, and selecting Script Object to New Window as > Create.
For some more information, you
can see Tibor's article, Generate DDL scripts.
If you are using Access, there isn't such an easy way to derive column definitions from the
schema, because these are no longer stored in the system tables (they used to be in MSysColumns).
You can at least verify the exact types and nature of each column
(instead of using generic descriptions like "it's a date column") by using the Documenter.
With your MDB file open, go to Tools | Analyze | Documenter, check the table(s) on the Tables
tab, and hit OK. You can hit Options to reduce the amount of data that comes back.
You used to be able to use File|Save As Table with these results, but not anymore. I'm not
sure of the best way to convert this to something you can post, but you may also want to look
at Article #2177 for some ways to derive a list using ASP.
To provide sample data, you can use this code from Vyas to generate INSERT
statements from your existing tables. Usually it is not necessary recreate your entire
data set, but make sure there is enough data to reproduce the problem. If your table structure
is simple, you will probably find it quicker to just whip up the INSERTs by hand.
Please do NOT provide sample data in tabular format, and do not supply dates in a regional
or otherwise ambiguous format (e.g. 05/03/04). You have no idea what language or regional
settings will be in