Re: Data in wrong columns after query changed

Of course that is the problem.

That's the main reason that we encourage the practice of explicitly 'naming'
the desired columns in every query. Most of us here constantly tell folks
that using "SELECT *" is inappropriate and places the queries in jeopardy of
failure (or producing inappropriate results) in the future.

If all of your queries were properly written, and listed the columns
desired, queries would not fail as a result of adding a new column, or
changing the column order. They just wouldn't deal with the now missing
'new' column and could be corrected as needed.

Also, good programming practices REQUIRE that you never change existing
procedures in a way that will 'break' other functionality. In the rare
circumstance where it is necessary to deliberately break existing
functionality, a complete test regimen and user acceptance cycle must be
invoked again.

There is no 'quick fix' for your problem. You have no alternative but to
manually find and repair all queries so affected. And in the process, you
may inadvertently 'break' other things. As the tag line below indicates,
chalk this one up to 'experience'.

--
Arnie Rowland
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous


"JerryWendell" <JerryWendell@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:82DFC3C7-0DF8-4574-936D-861D3207B8D9@xxxxxxxxxxxxxxxx
I should clarify that the second query (the one that references the changed
query), uses the "*" to select all columns from the first query.

"JerryWendell" wrote:

I added a field to the middle of an existing query. Another query that
referenced the changed query had data in the wrong columns.
For example, the original query had
TaskID, division, CostID, Amount
I changed it to have
TaskID, division, company, CostID, Amount
When I executed a query that referenced the changed query, CostID was
displayed in the company field and Amount was displayed in the CostID
field.

The only way I found to correct the problem was to go into every query
that
references the changed query and make a change and save it. This could
be
cumbersome if there are a lot of queries involved.

Is there a way to force all queries to be saved or some other way to get
SQLServer to recognize the change?

Thanks!


.

Relevant Pages

  • RE: Dynamically referencing a recordset?
    ... through that recordset to set the query parameters in VBA. ... to be the one who had to modify 1440 queries if there is a change in the ... different table schema, then you need 3, one for each record type. ... This is a database that tracks the production on records in another ...
    (microsoft.public.access.modulesdaovba)
  • Re: Was: what does "serialization" mean?
    ... > the specific queries up front. ... that the NEXT time the query is run the query is fast, ... data base, don't know squat" when in fact the Donald clone doesn't ... >> WHATEVER would probably be a separate query to summarize total sales. ...
    (comp.programming)
  • Re: Official Status of SQLServer 2005 ADP
    ... I have said that the support for SQL passthrough ... queries under MDB was bad and worst than the one offered by ADP while you ... > attempt to "pass through" every Access query against a linked ODBC ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Cluster synchronize
    ... queries per unit time. ... CPU is the ONLY bottleneck. ... increase in query capacity. ... queries that perform sequential I/O or queries performing random I/O. ...
    (microsoft.public.sqlserver.clustering)
  • Re: "Query Too Complex" Errors
    ... few dozens of queries, in the middle of which there's a long chain of ... we've been having a lot of those "Query Too ... some of the complexity in the SQL ... SQL statement you are working on. ...
    (microsoft.public.access.forms)