Conncetiviti error

I have this error only when reading a certain file from SQL
server, and not with all the other files, so it's very strange.
I have a Visual FoxPro cursoradapter who gets populated with a
record from a table in SQL server, and the CursorFill method of
the CursorAdapter (which populates it using the CursorAdapter
properties) raises this error:
Connectivity error: [ODBS SQL Server driver] [SQL Server] Line 1:
incorrect sintax near ")".
The message was in italian so I translated it.
I checked the CursorAdapter's SelList, the SelectCmd, the
KeyFieldList, the Cursorschema... none of them contains
parentheses except the selectcmd, as modified in the
BeforeCursorfill event. The selectcmd is the command that Visual
FoxPro will internally use to call SQL server and populate the
cursoradapter.
This select statement contains the list of fields, the FROM
clause and the following "WHERE" condition:
WHERE FLG_LOAD=0 and (substring(TAG1,1,16) >= ' '
and substring(TAG1,1,16)<=(SELECT
COALESCE(min(substring(TAG1,1,16)),'') FROM AR_ANAGR_ANA_IP WHERE
substring(TAG1,1,16) > ' ' and FLG_LOAD = .F.))
FLO_LOAD and TAG1 are both fields of that table.
Someone sees something strange, in that condition?
TIA
VilliHi
FLG_LOAD = .F.))
The ".F." is not a valid expression in SQL Server. Is it a variable, a value
or ?
Regards
Mike
"Villi Bernaroli" wrote:

> I have this error only when reading a certain file from SQL
> server, and not with all the other files, so it's very strange.
> I have a Visual FoxPro cursoradapter who gets populated with a
> record from a table in SQL server, and the CursorFill method of
> the CursorAdapter (which populates it using the CursorAdapter
> properties) raises this error:
> Connectivity error: [ODBS SQL Server driver] [SQL Server] Line 1:
> incorrect sintax near ")".
> The message was in italian so I translated it.
> I checked the CursorAdapter's SelList, the SelectCmd, the
> KeyFieldList, the Cursorschema... none of them contains
> parentheses except the selectcmd, as modified in the
> BeforeCursorfill event. The selectcmd is the command that Visual
> FoxPro will internally use to call SQL server and populate the
> cursoradapter.
> This select statement contains the list of fields, the FROM
> clause and the following "WHERE" condition:
> WHERE FLG_LOAD=0 and (substring(TAG1,1,16) >= ' '
> and substring(TAG1,1,16)<=(SELECT
> COALESCE(min(substring(TAG1,1,16)),'') FROM AR_ANAGR_ANA_IP WHERE
> substring(TAG1,1,16) > ' ' and FLG_LOAD = .F.))
> FLO_LOAD and TAG1 are both fields of that table.
> Someone sees something strange, in that condition?
> TIA
> Villi
>
>|||Mi e' parso che Mike Epprecht (SQL MVP) abbia scritto:

> Hi
> FLG_LOAD = .F.))
> The ".F." is not a valid expression in SQL Server. Is it
> a variable, a value or ?
Ooooooooooooooops!
Thanks, Mike :)
--
The answer to the ethernal question is:
put a read events after the launch of the form

confused connection-SQL7

I just had a very strange (and scary) experience; on my test machine I have one ODBC set up to connect to my test SQL server. I just realized that some of the tables I have linked to this SQL server in an Access database are actually linked to the SQL se
rver on the production database. How can this happen? I don't have an ODBC set up for the production database on the test machine at all. I did have the same passwords in both SQL servers and I just changed one but what else can I do to protect against
this?
Unless you have the same name or IP address or changed the Test server to
Production and kept the same name I'm not sure how this could happend.
Unless there was a change to DNS or WINS that changed the way the machine
names are resolved...
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||It may have just been viewing the tables based on the meta
data stored on the Access side - did you actually select,
insert, update or delete from the tables? .
You can get around this and other issues with linked tables
by using code to reattach the tables when the application
starts.
-Sue
On Sat, 17 Jul 2004 06:38:01 -0700, "PatO"
<PatO@.discussions.microsoft.com> wrote:

>I just had a very strange (and scary) experience; on my test machine I have one ODBC set up to connect to my test SQL server. I just realized that some of the tables I have linked to this SQL server in an Access database are actually linked to the SQL s
erver on the production database. How can this happen? I don't have an ODBC set up for the production database on the test machine at all. I did have the same passwords in both SQL servers and I just changed one but what else can I do to protect agains
t this?
|||Thanks for your input. I realized last night that the production server is listed as a remote server on the test server. Could this be how this happened?
Pat
"Kevin McDonnell [MSFT]" wrote:

> Unless you have the same name or IP address or changed the Test server to
> Production and kept the same name I'm not sure how this could happend.
> Unless there was a change to DNS or WINS that changed the way the machine
> names are resolved...
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>
|||Thanks for your reply. Yes I actually did update the production tables through Access.
"Sue Hoegemeier" wrote:
[vbcol=seagreen]
> It may have just been viewing the tables based on the meta
> data stored on the Access side - did you actually select,
> insert, update or delete from the tables? .
> You can get around this and other issues with linked tables
> by using code to reattach the tables when the application
> starts.
> -Sue
> On Sat, 17 Jul 2004 06:38:01 -0700, "PatO"
> <PatO@.discussions.microsoft.com> wrote:
server on the production database. How can this happen? I don't have an ODBC set up for the production database on the test machine at all. I did have the same passwords in both SQL servers and I just changed one but what else can I do to protect agai
nst this?
>
|||Yes, but you would have had to choose this server during the linking step
in Access.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||Then you have the same DSN on the machine which points to
the production server. Or you linked to the production
server. You can find the string used to link the tables in
MSysObjects under the Connect column.
-Sue
On Tue, 20 Jul 2004 05:28:02 -0700, "PatO"
<PatO@.discussions.microsoft.com> wrote:
[vbcol=seagreen]
>Thanks for your reply. Yes I actually did update the production tables through Access.
>"Sue Hoegemeier" wrote:
L server on the production database. How can this happen? I don't have an ODBC set up for the production database on the test machine at all. I did have the same passwords in both SQL servers and I just changed one but what else can I do to protect aga
inst this?[vbcol=seagreen]

confused connection-SQL7

I just had a very strange (and scary) experience; on my test machine I have
one ODBC set up to connect to my test SQL server. I just realized that some
of the tables I have linked to this SQL server in an Access database are ac
tually linked to the SQL se
rver on the production database. How can this happen? I don't have an ODBC
set up for the production database on the test machine at all. I did have
the same passwords in both SQL servers and I just changed one but what else
can I do to protect against
this?Unless you have the same name or IP address or changed the Test server to
Production and kept the same name I'm not sure how this could happend.
Unless there was a change to DNS or WINS that changed the way the machine
names are resolved...
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||It may have just been viewing the tables based on the meta
data stored on the Access side - did you actually select,
insert, update or delete from the tables? .
You can get around this and other issues with linked tables
by using code to reattach the tables when the application
starts.
-Sue
On Sat, 17 Jul 2004 06:38:01 -0700, "PatO"
<PatO@.discussions.microsoft.com> wrote:

>I just had a very strange (and scary) experience; on my test machine I have one ODB
C set up to connect to my test SQL server. I just realized that some of the tables
I have linked to this SQL server in an Access database are actually linked to the SQ
L s
erver on the production database. How can this happen? I don't have an ODB
C set up for the production database on the test machine at all. I did have
the same passwords in both SQL servers and I just changed one but what else
can I do to protect agains
t this?|||Thanks for your input. I realized last night that the production server is
listed as a remote server on the test server. Could this be how this happen
ed?
Pat
"Kevin McDonnell [MSFT]" wrote:

> Unless you have the same name or IP address or changed the Test server to
> Production and kept the same name I'm not sure how this could happend.
> Unless there was a change to DNS or WINS that changed the way the machine
> names are resolved...
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>|||Thanks for your reply. Yes I actually did update the production tables thro
ugh Access.
"Sue Hoegemeier" wrote:

> It may have just been viewing the tables based on the meta
> data stored on the Access side - did you actually select,
> insert, update or delete from the tables? .
> You can get around this and other issues with linked tables
> by using code to reattach the tables when the application
> starts.
> -Sue
> On Sat, 17 Jul 2004 06:38:01 -0700, "PatO"
> <PatO@.discussions.microsoft.com> wrote:
>
server on the production database. How can this happen? I don't have an OD
BC set up for the production database on the test machine at all. I did hav
e the same passwords in both SQL servers and I just changed one but what els
e can I do to protect agai
nst this?[vbcol=seagreen]
>|||Yes, but you would have had to choose this server during the linking step
in Access.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Then you have the same DSN on the machine which points to
the production server. Or you linked to the production
server. You can find the string used to link the tables in
MSysObjects under the Connect column.
-Sue
On Tue, 20 Jul 2004 05:28:02 -0700, "PatO"
<PatO@.discussions.microsoft.com> wrote:
[vbcol=seagreen]
>Thanks for your reply. Yes I actually did update the production tables thr
ough Access.
>"Sue Hoegemeier" wrote:
>
L server on the production database. How can this happen? I don't have an
ODBC set up for the production database on the test machine at all. I did h
ave the same passwords in both SQL servers and I just changed one but what e
lse can I do to protect aga
inst this?[vbcol=seagreen]