The query is simply
sqlString = "SELECT * FROM All Students"
but I get "Syntax error in FROM clause" when I try to run it. I assume
this is because my table is two words. How do I get Access to recognize
it?
Thanks,
Kevin
sqlString = "SELECT * FROM [All Students]"
--
Terry Kreft
<audl...@quasika.net> wrote in message
news:1132004896.0...@g49g2000cwa.googlegroups.com...
IMO good practice to always use square brackets around field/tables
names.
> <audl...@quasika.net> wrote in message
> news:1132004896.0...@g49g2000cwa.googlegroups.com...
>> I'm attempting to build a query that involves a table called "All
>> Students".
>>
>> The query is simply
>>
>> sqlString = "SELECT * FROM All Students"
>>
>> but I get "Syntax error in FROM clause" when I try to run it. I
>> assume this is because my table is two words. How do I get Access to
>> recognize it?
>>
>> Thanks,
>> Kevin
--
regards,
Bradley
A Christian Response
http://www.pastornet.net.au/response
If your convention involves using square brackets at all times that's fine
but it isn't necessarily good practice.
--
Terry Kreft
"Br@dley" <br...@usenet.org> wrote in message
news:oZ9ef.17751$Hj2....@news-server.bigpond.net.au...
> Terry Kreft wrote:
>> Square brackets i.e.
>>
>> sqlString = "SELECT * FROM [All Students]"
>
> IMO good practice to always use square brackets around field/tables names.
>
>> <audl...@quasika.net> wrote in message
>> news:1132004896.0...@g49g2000cwa.googlegroups.com...
>>> I'm attempting to build a query that involves a table called "All
>>> Students".
<SNIP>
As I said, my opinion only.
While I agree with the above (I never use spaces) you are assuming the
developer is the one creating the table/etc whereas in real life
developers are often fixing up someone else's work and don't have the
luxury of renaming all the database objects to conform to their personal
standards.
If you had spent as much time as I have fixing other peoples code you would
probably realise why it is better to espouse real good practices in code
writing/database creation rather than ones which would be irrelevant if the
work had been done properly in the first place.
--
Terry Kreft
"Br@dley" <br...@usenet.org> wrote in message
news:mKsef.18549$Hj2....@news-server.bigpond.net.au...
Another assumption? :)
I've 11+ years experience with Access development. More than enough to
have an idea of what I'm talking about.
> would probably realise why it is better to espouse real good
> practices in code writing/database creation rather than ones which
> would be irrelevant if the work had been done properly in the first
> place.
As I said, I agree with the implementation of standards when developing
a database.
However, I stand by my initial point. Most real world jobs that I have
been involved in no-one is there to "espouse" good practice to. The
original 'developer' (I use the term loosely as most aren't real
developers) is long gone and you've been called in to add reporting or
something. Their is usually a tight budget involved that does not allow
for the luxury of redesigning the application to conform to good
practice.
BYW 11+ years, means to me you are just reaching puberty in your programming
life, so that maybe explains something I hadn't taken into account <g>.
--
Terry Kreft
"Br@dley" <br...@usenet.org> wrote in message
news:Vsxef.18786$Hj2....@news-server.bigpond.net.au...
> However, I stand by my initial point. Most real world jobs that I
> have been involved in no-one is there to "espouse" good practice
> to. The original 'developer' (I use the term loosely as most
> aren't real developers) is long gone and you've been called in to
> add reporting or something. Their is usually a tight budget
> involved that does not allow for the luxury of redesigning the
> application to conform to good practice.
On any projects where I'm brought in to add something to the work of
another "developer," part of my estimate will include a cleanup
process, which is necessary before I'll agree to take over and
support any alterations to the application. This is a non-negotiable
part of the project (and needs to happn only once).
I can't waste my time repeatedly working around bad naming
conventions, and I refuse to do so. And the client pays me to fix
the things their previous developer did wrong. If they don't want to
pay me to do that, they can hire someone else to do the job.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
> .... part of my estimate will include a cleanup
> process, which is necessary before I'll agree to take over and
> support any alterations to the application. This is a non-negotiable
> part of the project (and needs to happn only once).
<>
> If they don't want to
> pay me to do that, they can hire someone else to do the job.
It's nice if you can afford that luxury.
> David W. Fenton wrote:
>> "Br@dley" <br...@usenet.org> wrote in
>> news:Vsxef.18786$Hj2....@news-server.bigpond.net.au:
><>
>
>> .... part of my estimate will include a cleanup
>> process, which is necessary before I'll agree to take over and
>> support any alterations to the application. This is a
>> non-negotiable part of the project (and needs to happn only
>> once).
>
><>
>
>> If they don't want to
>> pay me to do that, they can hire someone else to do the job.
>
> It's nice if you can afford that luxury.
It's not a luxury. I won't punish myself by taking projects where
the clients aren't interested in doing things right. I'm *saving*
them money in the long run, and saving myself gray hairs (or any
other developer who comes along after me).
Most clients can't determine what's required or not. I just make the
reworking of the app to meet my standards a required part of the
project, not even suggesting that it is in any way optional.
> It's not a luxury. I won't punish myself by taking projects where
> the clients aren't interested in doing things right. I'm *saving*
> them money in the long run, and saving myself gray hairs (or any
> other developer who comes along after me).
Sure, but "beggars can't be choosers" all the time in business.
> Most clients can't determine what's required or not.
Most know what they want and usually have tight budgets/red tape.
> I just make the
> reworking of the app to meet my standards a required part of the
> project, not even suggesting that it is in any way optional.
I'd love to be able to do that all the time but it just isn't going to
happen :)
> David W. Fenton wrote:
>> "Br@dley" <br...@usenet.org> wrote in
>> news:zLXef.19703$Hj2....@news-server.bigpond.net.au:
>>
>>> David W. Fenton wrote:
>>>> "Br@dley" <br...@usenet.org> wrote in
>>>> news:Vsxef.18786$Hj2....@news-server.bigpond.net.au:
>>> <>
>>>
>>>> .... part of my estimate will include a cleanup
>>>> process, which is necessary before I'll agree to take over and
>>>> support any alterations to the application. This is a
>>>> non-negotiable part of the project (and needs to happn only
>>>> once).
>>>
>>> <>
>>>
>>>> If they don't want to
>>>> pay me to do that, they can hire someone else to do the job.
>>>
>>> It's nice if you can afford that luxury.
>
>> It's not a luxury. I won't punish myself by taking projects
where
>> the clients aren't interested in doing things right. I'm
*saving*
>> them money in the long run, and saving myself gray hairs (or any
>> other developer who comes along after me).
>
> Sure, but "beggars can't be choosers" all the time in business.
Well, these days, I'm something of a beggar, but it's not because
of
these kinds of things that my business is slow -- it's because
there
just isn't work out there, and the clients with work aren't paying
quickly.
>> Most clients can't determine what's required or not.
>
> Most know what they want and usually have tight budgets/red tape.
If I say I cannot do B until I've done A, they have to pay for A.
Or, I could add the price of A into B and not include it in the
estimate at all.
But I'd rather be honest.
And there's also the advantage to be gotten from convincing them
that I'm concerned with long-term maintainability of their
application, that the money invested pays off in the long run by
making it easier to maintain and extend the application in the
future.
If I didn't actually believe that, I certainly wouldn't spend the
time on it.
>> I just make the
>> reworking of the app to meet my standards a required part of the
>> project, not even suggesting that it is in any way optional.
>
> I'd love to be able to do that all the time but it just isn't
> going to happen :)
Have you tried it? I don't find clients to be that unreasonable if
you take the time to explain to them why what you're proposing is
needed and why it benefits them in the long run.
Yes, of course. I'm not saying I've never had clients who are willing to
put in the resources to properly fix the database (you gotta love the
ones who say "sure go and do whatever you think needs to be done"). I'm
just stating that there are also those that don't. Typically you list
out everything and they tend to wittle out the things they don't won't
regardless of how much you protest. If I choose not to do it they will
go to another developer whose quote is lower. Sometimes,hopefully,
starting this way will lead to a longer term relationship where they
will feel more comfortable putting more resources into redesigning badly
build apps.
You use Square Brackets and you think this is Truth.
Then you find there are other solutions:
SELECT * FROM All_Students
SELECT * FROM `All Students`
And you wonder ....
Fortune, of course :-).
>
> You use Square Brackets and you think this is Truth.
> Then you find there are other solutions:
Horatio, you're dumbing down Shakespeare.
>
> SELECT * FROM All_Students
> SELECT * FROM `All Students`
>
> And you wonder ....
James A. Fortune
There is more in the world than you have dreamt of in all of your
philosophies, Horatio.
-- Hamlet Act1
On a midnight train to Beverly, MA:
Overheard from an elderly passenger going to Salem:
This astrology stuff really works.
Me:
So do you believe that God put messages in the stars for us to read?
Passenger:
I don't believe in God!
(heads turn toward her)
Truth? No, IMO it's just an easy way to make all objects names work in
code when spaces have been used and it also helps the name stand out
when reading the code. As with many things in Access there is 'more than
one way to skin the cat'.