Remote View Problem

[JRB-Bldr]

Can anyone think of an environment setting (e.g. SET <something> ON/OFF) which might prevent a Remote View from being created within a Database?

In an application I dynamically create a Remote View using code like:

OPEN DATABASE ThisDBC
SET DATABASE TO ThisDBC
CREATE SQL VIEW 'ThisView' REMOTE CONNECTION 'ThisConnect' AS SELECT * FROM RemoteData

  <Do some stuff>

DELETE VIEW ThisView

It is pretty simple.

However when I execute it within the application EXE on a workstation, it repeatedly fails.

Error Message:
Connectivity error: [Noble Systems Corp.][ATOMIX ODBC Driver]Unable to connect
Too 'generic' to know what is actually going wrong!

But when I terminate the EXE, go into VFP and immediately execute the same code within the the very same workstation from the Command Window, it works fine.

I have also tested running the EXE on my development workstation and it runs fine.

I am guessing that there is some subtle environment setting which is not being set as needed in the EXE within the problematic workstation, but I'm not sure where to look.

I am going to try to change the workstation's Domain privilages to see if that makes a difference, but since it works interactively under the same login within VFP, I doubt that is the issue.

Has anyone else run into a similar issue and discovered any parameter(s) might be the cause?

Thanks,
JRB-Bldr

 

[Mike Lewis]

JRB-Bldr,

It's difficult to be sure, but it seems likely that you are using a different version of the connection object ("ThisConnect") in each case. This in turn might be caused by a pathing issue.

Keep in mind that CREATE SQL VIEW will first look for the connection object in current database ("ThisDBC"). If it can't find it, it assumes it is an ODBC data source. If it's not, it will give an error.

So, if you have two copies of ThisDBC, and one of them contains ThisConnect and the other doesn't (or one of them has an invalid copy of ThisConnect), that would explain the behaviour you are seeing.

A good way to debug this might be to display the full path and name of the current database just before you issue the CREATE SQL VIEW.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[JRB-Bldr]

Mike - thanks for the reply.

"likely that you are using a different version of the connection object ("ThisConnect") in each case"

In both workstations the "ThisConnect" is an existing ODBC DSN within the workstation and it is configured the same on ALL workstations.

And when I independently tested the Connect of this ODBC DSN via a UDL connection, the connection worked fine.

Additionally when I execute this EXACT SAME code interactively via VFP on the same 'failing' workstation, I am using the same ODBC DSN reference and it works fine.

"if you have two copies of ThisDBC"

There is only a single copy of the 'ThisDBC' on the entire server.

If you can think of anything else, I'd welcome the input.

Thanks,
JRB-Bldr

 

[Mike Lewis]

JRB-Bldr,

Sorry my suggestions didn't help.

I wish I could suggest something else. You've obviously given this a lot of thought and tried all the obvious approaches.

Anybody else here go any ideas?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[pthalacker]

go into VFP and immediately execute the same code within the the very same workstation from the Command Window

In other words you type:

DO MyApp.exe

in the Command Window?

There's no chance the DBC is included in the Project is there?

pamela

 

[JRB-Bldr]

Pamela - No I do not type

 DO MyApp.exe

Instead I type (line-by-line into the VFP Command Window)

 OPEN DATABASE ThisDBC
 SET DATABASE TO ThisDBC
 CREATE SQL VIEW 'ThisView' REMOTE CONNECTION 'ThisConnect' AS SELECT * FROM RemoteData

If the code executes on the 'failing' workstation as part of the EXE, it will fail.

If I run in interactive Development mode on the 'failing' workstation with a

DO ThisUtility.FRX

and SUSPEND when I encounter the error, I then ACTIVATE WINDOW TRACE to see where the problem was encountered.
I next enter the line-by-line code into the Command Window, and the CREATE SQL VIEW code fails.

But if I immediately exit VFP and launch a new VFP session and enter the code above, it works.

If this failed EVERY time, I would question the code, but since it runs successfully in both the EXE and in interactive Development mode on my development workstation, I am left questioning what is unique to this other workstation (or its VFP environment) that is causing the failure.

Thanks,
JRB-Bldr

 

[JRB-Bldr]

I thought that I'd follow-up on this issue.

Even though the resolution has not been 100% confirmed, I did seem to have some luck over the last couple of days.

Is it because the data was such that the 'failing' utility was not accessed, or not I cannot say for certain. But typically it is accessed each day, so the assumption is that the code executed.

And the EXE code did not error out.

What did I do?

Out of desperation and 'grasping for straws' I re-installed the VFP7 EXE onto the workstation. The setup EXE that I used was created quite a while ago using Install Shield.

If the problem returns, I'll re-post.
For now, let's keep our fingers crossed!

Thanks,
JRB-Bldr