sql statement throws 1707 (cdx not found) error but cdx is present and OK 4

[CJMK]

Note: very simple system to provide convenient management information from a single table obtained by combining data from three tables using sql.
I have:
Made sure the cdx is indeed present and functional
Built project, exe, and used inno setup to compile install
Works fine on my win 10 computer and wife's win 7
Called the code from a method in the load of the form.
Moved the code into a prg instead to no effect
Put the install in dropbox so no question all are from same source
Placed a messagebox just prior to the problem to make sure we are right there.
(obviously getting a bit desperate by now)
Nevertheless, my primary user (also on win 10) gets the 1707 cdx not found error

The "offending code"
SELECT r.pin_player as id,r.rating,MAX(r.elab_date) as rate_date ;
FROM ratings r LEFT OUTER JOIN agamembers a ON a.id = r.pin_player ;
GROUP BY r.pin_player ;
INTO CURSOR cur_ratings ;
readwrite

I attach the errorlog from the version with the code in the method called from load

 

[Olaf Doschke]

I guess you have a UAC file redirection.
Where is data installed to?
Do you REINDEX or INDEX in code?

Since you mention you created an installer with inno, let it install data into CSIDL_COMMON_APPDATA.
See here, for Inno that's {commonappdata}

http://www.jrsoftware.org/ishelp/index.php?topic=consts

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[mjcmkrsr]

Hi,

Please don't use single letters as table Alias

JOIN agamembers a ON a.id = r.pin_player ;

and have a look at (from Hacker'sGuide to Visual Foxpro - Tamar A. Granor, Ted Roche et al)

The Single Letter Blues

On the whole, the designers of Visual FoxPro have done a tremendous job marrying object-orientation to Xbase. But there are places where the marriage seems a little rocky. The use of single-letter identifiers is one of them.

Traditionally, the letters A through J are alternate names for the first 10 work areas. (When the number of work areas went up to 25, Fox Software didn't extend this convention. It's just as well—they'd have a heckuva time finding 32,767 different characters to represent the work areas in Visual FoxPro.) In addition, the letter M was reserved to indicate that what followed was a memory variable.

So, how would this cause you any trouble? Well, what if you have a table named C.DBF? When you open it with USE C, you'd expect it to have the alias of "C", right? Only if you're really lucky. Because "C" is reserved for the third work area, the only way C.DBF will have an alias of "C" is if you open it in the third work area. Otherwise, it'll have an alias of the work area it's opened in ("A" through "J" if it's opened in one of the first 10 work areas, or "W" followed by the work area number if not). So, when you use code like SELECT C to select the table, you'll really be selecting the third work area, which may have an entirely different table open or no table open at all.

OOP makes it even worse. Object-orientation uses the same type of "dot" notation that fields in tables do to spell out the complete name of an object, like frmMyForm.grdMainGrid.colName.txtName. So what's the problem? There is none, unless you try to use one of the letters A-J or M for the name of an object. Code like the following:

a=CreateObject("form")
a.Caption="My Form"
is doomed to failure. You can create the form, but the assignment blows up on you as VFP goes looking for a field named Caption in the first work area.

Of course, single-letter variable and table names are a lousy idea anyway (most of the time—we're still fond of variables like x, y, z, and o for quick and dirty testing), so the workaround for this isn't terribly painful. It's like the old joke—"Doctor, it hurts when I do this."—"Then don't do that." Use names longer than one character and you'll never run into this problem.

hth

MK

 

[Olaf Doschke]

Single letter alias name can only be a problem for the first 10 letters a-j.
Try for yourself. Start a new VFP session, have no tables open:

SELECT j
? SELECT() && outputs 10
SELECT k && error [Alias "K" is not found]

So r is not the problem.

You may even use m:

ID = "TEST"
Select m.id from Sys(2005)
Select m.id from Sys(2005) m

It's good to avoid any conflict, though and rather not use single letters for aliases, keywords for names, etc., I agree with that, but it can't be the root of your problem, I still am pretty sure it has to do with installing the DBF in program files and redirection of writing to protected files into users VirtualStore folder.

If you already are on the level of making a setup you should know that there are system folders and application data goes into system folders for data.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[CJMK]

Olaf,
Thanks. and sorry for delay in responding. Life interrupting. Yes, I did open and reindex the files prior to the problem point. forgot to mention that on my list. I have now tried using two letter aliases, to no effect. I have done only a few very simple setups, so not well versed there. And no experience with UAC, which I am now taking time to learn. Confusing issue is that three other computers - 2 win 10 - are taking it in just fine, awaiting tests on a couple more. Just to clarify -- is the exe I build 32 or 64 bit, (and how can I tell?) I am installing in program files (x86) believing that it is 32. Since the system is entirely self contained, I have in the (distant) past (20th century?), put the whole thing elsewhere, such as the root with no problems.
Am thinking it might be a system configuration issue, and planning look at the system info in the error logs from the different test computers.

 

[Dan Olsson]

For what it's worth, I have about 50 installations around Sweden and I always stay (far) away from Program Files.
Just the idea of having spaces in the path doesn't appeal to me. My setup defaults to C:\FOX on the server but they can change it at will, except for the Program Files directories. My systems runs entirely from the server, so the only thing one need to do on the client is making a shortcut to the EXE on the server. Maybe it's a LITTLE slower running everything from the server, but it makes maintenance so much easier. In practice it might not be slower at all since you get rid of UAC redirecting things.
/Dan

 

[Dan Olsson]

PS. and your EXE is 32bit since VFP is... (unless you use the illegal non-Microsoft VFP10)

 

[CJMK]

That's what I thought. Never heard of a mythic vfp10. But by now, (in my book at least) it surely would make sense to allow it to go open source. Good to get the feedback on location. If nothing else works, I will go back to the root of c:
No servers here. This will always be stand alone. And the data set is small -- ~ 24000 records in the main file and fewer in the others.

 

[Olaf Doschke]

You can and should install the EXE at Program Files (x96), yes it's always 32but, but the data, the DBF and its CDX should rather go into data folders. On Win10 that's C:\ProgramData\Yourapp\, differ in Win7 and XP, but Inno will know where to put it when you work with {commonappdata}.

I didn't recommend installing all into one place, you can install your EXE in the usual program files and data separate from that.

In your EXE you again need to find out where that is and you can see the side topic discussion about whether to use System32 vs SysWow64 and the related API function to determine several system folders in thread184-1793731

Besides, you may install into Documents, too. In some way a DBF also could be seen as a document (besides ClickOnce deployment even installs apps into users documents folder to enable installing without admin privileges secured with low permissions (in a way sandboxed).

Indeed for simplicity sake you can simply install into C:\yourapp\ and have that problem out of the way and may find out what else is wrong. You may have had the DBF open when compiling the Inno project causing it to fail including the DBF. Whatever. Or Inno indeed automatically separated the DBF file location from the EXE and now your EXE still expects the DBF to be in the program files folder.

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name

 

[CJMK]

Olaf -- and all -- Thanks many times sorry if I missed a "great post" anywhere
I solved the issue by keeping the exe, etc in x86 and putting the data in the root
using commonappdata in INNO left me with the problem of setting the vfp path to find the data. I know there must be an answer, but couldn't find it, so took the simple fix, which works everywhere (5 different computers now.)
Would appreciate a hint on using commonappdata if you can do that easy.

 

[Olaf Doschke]

Mike Lewis posted a solution to that:

http://www.hexcentral.com/articles/foxpro-folders.htm

And don't use root itself, in many cases group policies disallow writing to root, too. I guess you meant C:\yourappdata\your.dbf or something similar to that. It's just a bit of clutter if everyone would do that, but indeed even some customers use own folders for company applications besides having data on public file shares or rather in MSSQL servers, but that's a different situation anyway.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

Another method to find out should be possible by letting the Inno setup write a setup log file including that path used. Or a registry entry.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name