>I'm having a strange problem with an application at a client site.
>
>The problem doesn't exhibit itself on my home PC or on any PC I've tried it on except at the client site.
>
>The client is using Microsoft Small Business Server with workstations having Windows 95 OSR2 rev C installed. The application [bbc.exe] was developed using Visual FoxPro 5.0a [05.00.00.0415].
>
>Under Small Business Server, when the user tries to run a particular report, he gets the following error:
>
>BBC.EXE has caused an exception. Access violation at 0XC000005 address 0x1017FB4D
>
>Under Windows 95, the error is:
>
>An invalid page fault has been caused by VFP500.DLL at 0157:1017FB4D
>

These two errors are equivalent in their layer, but they error being trapped is slightly different (under one, it's an error addressing memory not belonging to the process, in the other, a BOUNDS check is out of range); it's curious that they occur at the same virtual address under two different operating systems that allocate memory in different ways. Is the address really the same, and repeats consistently at the same virtual memory address under both operating systems?

>These errors do not occur anywhere else in the application. The actual report form seems to be fine, as it is used elsewhere in the application without causing this error.
>
>The SQL statement which seems to trigger the error is:
>
> select ordhead.*, customer.ct_customer_name ;
> from ordhead, customer ;
> where ordhead.so_cust_id = customer.ct_customer_code ;
> and ordhead.so_number not in (select grn.grn_ordernumber from grn where !empty(alltrim(grn.grn_jobnumber))) ;
> into cursor jobrep ;
> order by ct_customer_name, ordhead.so_number
>
>This works fine under Windows 95a.
>
>Anybody got any ideas ?

I have no idea why you're getting this, since it looks quite legal and valid; I'm a fan of simplification, though, and in this case, you could simplify your WHERE clause. Assuming that grn_jobnumber is a character field, the logical condition:

! EMPTY(ALLTRIM(grn.grn_jobnumber))

is exactly identical to:

! EMPTY(grn.grn_jobnumber)

This should have no reason to fix things, but it will run faster, and if it's something bizarre, like a piece of code lying on a page boundary (memory is managed by both operating systems in fixed-sized piece called pages, and there are a few situations where things align in memory badly across multiple page boundaries, and cause memory access errors. These are tough errors to track down, and usually are fixed by forcing something to be laid out in memory slightly differently. As a blind stab, simplifying this statement might change the condition enough to fix it.)

I'd try to focus on what the two share in common; since it's in a report, one obvious problem might be the printer driver. HP print drivers, especially the ones shipped by HP, rather than the ones biundled with Microsoft's operating systems, have a long history of causing strange errors like this. If you're using an HP printer, and both the server and workstations use the same printer, and you're using an HP-provided driver, try changing the print driver to one of those supplied with SBS. I've seen problems in a number of applications caused by interactions with HP drivers; I've personally had problems with the drivers for the HP 5si and HP 4000 laser printers, and have seen others reporting problems with the HP 6 series printers. Backing off to an older, MS-supplied driver (my fallback for the 5si is usually the MS-provided HP IIIsi driver, and the HP LaserJet 4 driver for the 4000 on the NT distribution; use the operating system distribution for the system hosting the printer to provide both the NT and Win95 driver, and let the client operating system pick up the driver from the system sharing the printer, rather than installing the driver individually on each system. SBS will let you load both NT and Win9x drivers so that when the printer is attached by another station, the driver associated with the printer is picked up and provided from the server. this makes changing drivers much easier - updating the server will automagoically cause all the other stations to get the updated driver.)