Re: Recordsource only available to Administrator on clients

Sylvain,

To follow-up on the troubleshooting steps you suggested:

In the ADP itself, when a connection is established under a non-
Administrator Windows logon, all stored procedures, for example, are
present and accounted for, appearing in the database window in the
format of "uspPt (dbo)", for example. Even though the green circle-
white arrow head is absent in SSMSE, just as in SSMSE the stored
procedure executes - either delivering the last record per the usf, or
a specified PtID if entered via the execution window. However, as I
mentioned before, when the icon in SSMSE is not green, the form does
not populate correctly.

In case this information is helpful, I further noted that the form
DOES display the dbo.tblPt.BirthDate field data and DOES display the
PtID in its field (each text boxes). However, none of the lookup
combo boxes populate (which comprise the majority of the fields on
this form). Further mystifying to me, in design view, all fields show
a warning of "This control has an invalid control source," INCLUDING
the birthdate and ID fields!

The problem is reproduced with an interesting variation by using an
explicit select statement for the recordsource via the form's property
***, such as "SELECT PtID, LastNameID, Birthdate FROM dbo.tblPt
WHERE (PtID=1065)" - In form view, the lookup combo does not
populate, as before. In contrast to the native stored procedure case,
however, in the design view none of the fields named in the select
statement show an "invalid control source" error.

I have not learned how to use the SQL profiler yet, so I can't report
on this.

No matter what interesting types of results may be yielded by tweaking
the inputs, the essence of the problem is clearly revealed in SSMSE -
What is the significance of the absence of the green circle/white
arrow in an otherwise "connected" database?, and how is it to be made
green for non-Administrator logons? My interpretation of this problem
is that Windows, via integrated security, is overriding the otherwise-
available SQL Server permissions, effectively preventing the ADP from
running properly.

Another obvious question would be whether I should cut my losses on
the ADP format altogether. The very reason I learned to use SQL
Server was for its advertised multiuser superiority. If Microsoft
will pull the plug on ADPs, surely, even if I was willing to revise
the system to a linked table SQL Server/Access format as seemingly
recommended these days, that configuration will be next on the
deprecation list. Having witnessed the rise and fall of ADO as an
outsider, my guess would be that today's promised land of dotNet will
be tomorrow's regret. It seems that SQL Server should be designed to
have its "own" front for the lowly SQL Server (Express) consumers like
me.

.

Loading