Thanks for the suggestions. Turns out I was right: I _was_ missing
something obvious - results had token as char(4), tokens had token as
varchar(4). Because the columns aren't the same they aren't treated as
identical so the query builder won't accept the unqualified name.
Next task is to work out
On 09/07/2016 01:11 PM, Geoff Winkless wrote:
On 7 Sep 2016 9:01 p.m., "Adrian Klaver" mailto:adrian.kla...@aklaver.com>> wrote:
What happens if you table qualify all the references to token?
Oh it definitely fixes it; I was more confused why it works on one
server and not another. I thought p
On 7 Sep 2016 9:01 p.m., "Adrian Klaver" wrote:
> What happens if you table qualify all the references to token?
Oh it definitely fixes it; I was more confused why it works on one server
and not another. I thought perhaps there was a config option to allow more
lax naming in this way. If not I'll
On 9/7/2016 12:53 PM, Geoff Winkless wrote:
I'll start by saying that I'm sure I'm missing something obvious...
I have a query that is working fine on all my servers except one. The
only obvious difference is that the failing one is running 9.5.3,
while most are running 9.5.4, but since the quer
On 09/07/2016 12:53 PM, Geoff Winkless wrote:
I'll start by saying that I'm sure I'm missing something obvious...
I have a query that is working fine on all my servers except one. The
only obvious difference is that the failing one is running 9.5.3,
while most are running 9.5.4, but since the qu
I'll start by saying that I'm sure I'm missing something obvious...
I have a query that is working fine on all my servers except one. The
only obvious difference is that the failing one is running 9.5.3,
while most are running 9.5.4, but since the query works on a 9.5.1 box
I also have I can't ima
