Prev: how to update a field record based on inputbox?
Next: combo box fills in arbitrary value
From: Boggle on 14 May 2010 07:57
I have a datasheet form (actually it's a subform, but this happens if you
look at the subform on its own). It has a SQL query for a record source
which joins three tables, and uses aliases (AS) for those tables. The
displayed field from two of the tables has the same name in each. (The SQL
is generated from table definitions and it has to handle the possibility that
the same table will be referenced in two different joins (example
employee->location, employee->manager->location), so aliasing is not
optional.) All works fine.

Then you use the built-in sorting feature to sort one of the fields (one
which shares a name with another joined table) ... still fine. Go into
design view and look at Order By, and it looks like:
[Lookup_<control>].[<field>]
That's OK.

Then hit save, and Access takes it upon itself to rewrite the clause into
something it can't recognise:
Lookup_<control>.[<alias>.<field>]

Doh. Presumably it thinks the alias is necessary because of the shared
name, though of course it isn't, because we have the control name. And why
are there two separate pieces of code writing that clause?

You can carry on, and switch between form view and design view no problem.
But when you close and reopen the form, you get:
Invalid bracketing of name 'Lookup_<control>.[<alias>.<field>]'
and the form will not open. (As a subform, it comes up blank.)

Filtering triggers the same problem.

Clearly this is a bug, but I don't know how to report it. I could read the
Order By and Filter clauses on load and try and patch them up but that seems
a bit horrible. Any ideas?
From: Boggle on 14 May 2010 10:05
By the way this is Access 2007.

I just wrote a simple cleanup routine (within any pair of square brackets,
split by periods, and replace the contents with the last token), but the
syntax check occurs before Open and Load. Which means there is no workaround
- if you do the edit at any other time then you have to save the form ... and
Access kindly screws the clause up again as it saves.

I'm surprised this hasn't come up before - surely there are other people out
there who use datasheets, and not completely trivial joins? With users who
like to sort and filter?

"Boggle" wrote:

> I have a datasheet form (actually it's a subform, but this happens if you
> look at the subform on its own). It has a SQL query for a record source
> which joins three tables, and uses aliases (AS) for those tables. The
> displayed field from two of the tables has the same name in each. (The SQL
> is generated from table definitions and it has to handle the possibility that
> the same table will be referenced in two different joins (example
> employee->location, employee->manager->location), so aliasing is not
> optional.) All works fine.
>
> Then you use the built-in sorting feature to sort one of the fields (one
> which shares a name with another joined table) ... still fine. Go into
> design view and look at Order By, and it looks like:
> [Lookup_<control>].[<field>]
> That's OK.
>
> Then hit save, and Access takes it upon itself to rewrite the clause into
> something it can't recognise:
> Lookup_<control>.[<alias>.<field>]
>
> Doh. Presumably it thinks the alias is necessary because of the shared
> name, though of course it isn't, because we have the control name. And why
> are there two separate pieces of code writing that clause?
>
> You can carry on, and switch between form view and design view no problem.
> But when you close and reopen the form, you get:
> Invalid bracketing of name 'Lookup_<control>.[<alias>.<field>]'
> and the form will not open. (As a subform, it comes up blank.)
>
> Filtering triggers the same problem.
>
> Clearly this is a bug, but I don't know how to report it. I could read the
> Order By and Filter clauses on load and try and patch them up but that seems
> a bit horrible. Any ideas?
From: Boggle on 14 May 2010 10:51
It gets worse. I removed the aliases just to see what happened. I am still
referencing two fields with the same name in different tables. The Order By
clause is still fine until you save:
[Lookup_<control>].[<field>]

and when you save it goes to:
Lookup_<control>.[<table1>.<field>]

where table1 is always the first joined table with that field name. That
that still works if you sort in the column relating to the first joined table
(so apparently it isn't a syntax problem any more). But if you sort in the
column from the second joined table, then the control doesn't refer to
<table1>, and you get the invalid bracket error. (Though clearly it isn't
the brackets which are the problem.)

By the way my controls are combo boxes so you can drop down and see a list
of all valid entries in the column. But I can't see what that would have to
do with it.

It all worked fine in Access 2003.

"Boggle" wrote:

> By the way this is Access 2007.
>
> I just wrote a simple cleanup routine (within any pair of square brackets,
> split by periods, and replace the contents with the last token), but the
> syntax check occurs before Open and Load. Which means there is no workaround
> - if you do the edit at any other time then you have to save the form ... and
> Access kindly screws the clause up again as it saves.
>
> I'm surprised this hasn't come up before - surely there are other people out
> there who use datasheets, and not completely trivial joins? With users who
> like to sort and filter?
>
> "Boggle" wrote:
> ...

From: KARL DEWEY on 14 May 2010 11:15
Have you tried to do the SQL in a query rather than in the form?

--
Build a little, test a little.


"Boggle" wrote:

> It gets worse. I removed the aliases just to see what happened. I am still
> referencing two fields with the same name in different tables. The Order By
> clause is still fine until you save:
> [Lookup_<control>].[<field>]
>
> and when you save it goes to:
> Lookup_<control>.[<table1>.<field>]
>
> where table1 is always the first joined table with that field name. That
> that still works if you sort in the column relating to the first joined table
> (so apparently it isn't a syntax problem any more). But if you sort in the
> column from the second joined table, then the control doesn't refer to
> <table1>, and you get the invalid bracket error. (Though clearly it isn't
> the brackets which are the problem.)
>
> By the way my controls are combo boxes so you can drop down and see a list
> of all valid entries in the column. But I can't see what that would have to
> do with it.
>
> It all worked fine in Access 2003.
>
> "Boggle" wrote:
>
> > By the way this is Access 2007.
> >
> > I just wrote a simple cleanup routine (within any pair of square brackets,
> > split by periods, and replace the contents with the last token), but the
> > syntax check occurs before Open and Load. Which means there is no workaround
> > - if you do the edit at any other time then you have to save the form ... and
> > Access kindly screws the clause up again as it saves.
> >
> > I'm surprised this hasn't come up before - surely there are other people out
> > there who use datasheets, and not completely trivial joins? With users who
> > like to sort and filter?
> >
> > "Boggle" wrote:
> > ...
>
From: Boggle on 14 May 2010 11:26
Thanks for the suggestion - but it didn't help. After saving, Order By
becomes:
Lookup_<control>.[<query>.<table1>.<field>]

and again, table1 is always the first table joined in the query, and only
matches up with the controls that refer to that table.

"KARL DEWEY" wrote:

> Have you tried to do the SQL in a query rather than in the form?
>
> --
> Build a little, test a little.
>
>
> "Boggle" wrote:
>
> > It gets worse. I removed the aliases just to see what happened. I am still
> > referencing two fields with the same name in different tables. The Order By
> > clause is still fine until you save:
> > [Lookup_<control>].[<field>]
> >
> > and when you save it goes to:
> > Lookup_<control>.[<table1>.<field>]
> >
> > where table1 is always the first joined table with that field name. That
> > that still works if you sort in the column relating to the first joined table
> > (so apparently it isn't a syntax problem any more). But if you sort in the
> > column from the second joined table, then the control doesn't refer to
> > <table1>, and you get the invalid bracket error. (Though clearly it isn't
> > the brackets which are the problem.)
> >
> > By the way my controls are combo boxes so you can drop down and see a list
> > of all valid entries in the column. But I can't see what that would have to
> > do with it.
> >
> > It all worked fine in Access 2003.
> >
> > "Boggle" wrote:
> >
> > > By the way this is Access 2007.
> > >
> > > I just wrote a simple cleanup routine (within any pair of square brackets,
> > > split by periods, and replace the contents with the last token), but the
> > > syntax check occurs before Open and Load. Which means there is no workaround
> > > - if you do the edit at any other time then you have to save the form ... and
> > > Access kindly screws the clause up again as it saves.
> > >
> > > I'm surprised this hasn't come up before - surely there are other people out
> > > there who use datasheets, and not completely trivial joins? With users who
> > > like to sort and filter?
> > >
> > > "Boggle" wrote:
> > > ...
> >
 |  Next  |  Last
Pages: 1 2
Prev: how to update a field record based on inputbox?
Next: combo box fills in arbitrary value