**
Joel,

Matt helped me figure this out - I was searching on the Assignee Group field of a data form and so it was comparing the name of the group to the number of the group - thus not finding any records.

The table form lives on a Display-Only form and uses Display-Only fields as variables instead of using literals in the search criteria for the table. The table form is showing data from a data form of course. I guess I wasn't clear in my post - I thought I was but I was more concerned with getting across that the variables were display-only.

-----Original Message-----
From: ARSLIST [mailto:ARSlist@EARTHLINK.NET]
Sent: Monday, December 30, 2002 6:58 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: Table Fields - Refreshing and Field Values


**
Shannon,
How can you search a display-only form ? There aren't any records in the DB
to be searched. Try pointing your table to a form with data and see if it works.
HTH,
Joel

QMX Support Services, Inc.
Joel D. Sender,
Director of Western Operations
JSender@QMXS.com www.QMXS.com




-----Original Message-----
From: owner-arslist@arslist.org [mailto:owner-arslist@arslist.org]On Behalf Of Shannon Davis
Sent: Monday, December 30, 2002 1:01 PM
To: 'arslist@arslist.org'
Subject: Table Fields - Refreshing and Field Values



**
I have just built a table that looks at some display-only fields to get its search criteria. The table is on a Display-Only form. Not like the person would type in search criteria and it uses that - no. Rather, the person selects the "Department" they wish to view, and it shows records from that department.

Here's my selection criteria.
('Department' = $selDepartment$) AND ( 'dateAttendance' >= $From$) AND ( 'dateAttendance' <= $To$) AND ( 'Status' != "Cancelled")

Even if I refresh, this doesn't work. I have two theories:
1) It looks at teh values of these fields only when first loading, and doesn't check them when refreshing the search criteria. So, when the form and table are loaded, selDepartment is NULL and it isn't seeing that the user is selecting a value afterwards.
2) The records are visible only to the group (department), the manager (user of the app in this case), and the submitter. In my case, I am using a test account that is a member of the department, the manager of the group, AND the submitter. Still, perhaps when the table tries to retrieve the records, maybe it doesn't have permissions to them.

I have a 4.5.2 server and a 4.5.2 user tool. I do have the 5.1 user tool installed and have tried it as well. It has the same issues and furthermore, I have another Active Link that loads up the current user's name, manager, and department upon loading this form - and that doesn't work in the 5.1 tool. This worries me but since everyone here is using 4.5.2 for now, I am not concerning myself with it. It does make me wonder what will happen when we upgrade however.



---
Shannon B. Davis
Software Engineer - End User Applications
Boston Communications Group, Inc.
bcgi (781) 904-5328
sdavis@bcgi.net


You may also control your subscription options, including UNSUBSCRIBE, at http://www.ARSLIST.org This posting was submitted via the Web interface

You may also control your subscription options, including UNSUBSCRIBE, at http://www.ARSLIST.org This posting was submitted via the Web interface

You may also control your subscription options, including UNSUBSCRIBE, at http://www.ARSLIST.org This posting was submitted via the Web interface

**
I have just built a table that looks at some display-only fields to get its search criteria. The table is on a Display-Only form. Not like the person would type in search criteria and it uses that - no. Rather, the person selects the "Department" they wish to view, and it shows records from that department.

Here's my selection criteria.
('Department' = $selDepartment$) AND ( 'dateAttendance' >= $From$) AND ( 'dateAttendance' <= $To$) AND ( 'Status' != "Cancelled")

Even if I refresh, this doesn't work. I have two theories:
1) It looks at teh values of these fields only when first loading, and doesn't check them when refreshing the search criteria. So, when the form and table are loaded, selDepartment is NULL and it isn't seeing that the user is selecting a value afterwards.
2) The records are visible only to the group (department), the manager (user of the app in this case), and the submitter. In my case, I am using a test account that is a member of the department, the manager of the group, AND the submitter. Still, perhaps when the table tries to retrieve the records, maybe it doesn't have permissions to them.

I have a 4.5.2 server and a 4.5.2 user tool. I do have the 5.1 user tool installed and have tried it as well. It has the same issues and furthermore, I have another Active Link that loads up the current user's name, manager, and department upon loading this form - and that doesn't work in the 5.1 tool. This worries me but since everyone here is using 4.5.2 for now, I am not concerning myself with it. It does make me wonder what will happen when we upgrade however.



---
Shannon B. Davis
Software Engineer - End User Applications
Boston Communications Group, Inc.
bcgi (781) 904-5328
sdavis@bcgi.net


You may also control your subscription options, including UNSUBSCRIBE, at http://www.ARSLIST.org This posting was submitted via the Web interface

**
Shannon,
How can you search a display-only form ? There aren't any records in the DB
to be searched. Try pointing your table to a form with data and see if it works.
HTH,
Joel

QMX Support Services, Inc.
Joel D. Sender,
Director of Western Operations
JSender@QMXS.com www.QMXS.com




-----Original Message-----
From: owner-arslist@arslist.org [mailto:owner-arslist@arslist.org]On Behalf Of Shannon Davis
Sent: Monday, December 30, 2002 1:01 PM
To: 'arslist@arslist.org'
Subject: Table Fields - Refreshing and Field Values



**
I have just built a table that looks at some display-only fields to get its search criteria. The table is on a Display-Only form. Not like the person would type in search criteria and it uses that - no. Rather, the person selects the "Department" they wish to view, and it shows records from that department.

Here's my selection criteria.
('Department' = $selDepartment$) AND ( 'dateAttendance' >= $From$) AND ( 'dateAttendance' <= $To$) AND ( 'Status' != "Cancelled")

Even if I refresh, this doesn't work. I have two theories:
1) It looks at teh values of these fields only when first loading, and doesn't check them when refreshing the search criteria. So, when the form and table are loaded, selDepartment is NULL and it isn't seeing that the user is selecting a value afterwards.
2) The records are visible only to the group (department), the manager (user of the app in this case), and the submitter. In my case, I am using a test account that is a member of the department, the manager of the group, AND the submitter. Still, perhaps when the table tries to retrieve the records, maybe it doesn't have permissions to them.

I have a 4.5.2 server and a 4.5.2 user tool. I do have the 5.1 user tool installed and have tried it as well. It has the same issues and furthermore, I have another Active Link that loads up the current user's name, manager, and department upon loading this form - and that doesn't work in the 5.1 tool. This worries me but since everyone here is using 4.5.2 for now, I am not concerning myself with it. It does make me wonder what will happen when we upgrade however.



---
Shannon B. Davis
Software Engineer - End User Applications
Boston Communications Group, Inc.
bcgi (781) 904-5328
sdavis@bcgi.net


You may also control your subscription options, including UNSUBSCRIBE, at http://www.ARSLIST.org This posting was submitted via the Web interface

You may also control your subscription options, including UNSUBSCRIBE, at http://www.ARSLIST.org This posting was submitted via the Web interface

**
**

Try opening the form the table field is pointing to (as the user you are using), and enter your table field qualification into the advanced search bar, substituting the variables (stored in your display only fields) for the variable name. Are you able to retireve the expected records this way?



Kind Regards,

Axton Grams

University of North Texas

ACS Remedy, Computing Center

Web Site: http://remedy.unt.edu/helpdesk/

Email: awg0008@unt.edu

Phone: 940-565-3287

Cell: 903-624-7133

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of ARSLIST
Sent: Monday, December 30, 2002 5:58 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: Table Fields - Refreshing and Field Values



Shannon,

How can you search a display-only form ? There aren't any records in the DB

to be searched. Try pointing your table to a form with data and see if it works.

HTH,

Joel



QMX Support Services, Inc.
Joel D. Sender,
Director of Western Operations
JSender@QMXS.com www.QMXS.com




-----Original Message-----
From: owner-arslist@arslist.org [mailto:owner-arslist@arslist.org]On Behalf Of Shannon Davis
Sent: Monday, December 30, 2002 1:01 PM
To: 'arslist@arslist.org'
Subject: Table Fields - Refreshing and Field Values

**

I have just built a table that looks at some display-only fields to get its search criteria. The table is on a Display-Only form. Not like the person would type in search criteria and it uses that - no. Rather, the person selects the "Department" they wish to view, and it shows records from that department.



Here's my selection criteria.

('Department' = $selDepartment$) AND ( 'dateAttendance' >= $From$) AND ( 'dateAttendance' <= $To$) AND ( 'Status' != "Cancelled")



Even if I refresh, this doesn't work. I have two theories:

1) It looks at teh values of these fields only when first loading, and doesn't check them when refreshing the search criteria. So, when the form and table are loaded, selDepartment is NULL and it isn't seeing that the user is selecting a value afterwards.

2) The records are visible only to the group (department), the manager (user of the app in this case), and the submitter. In my case, I am using a test account that is a member of the department, the manager of the group, AND the submitter. Still, perhaps when the table tries to retrieve the records, maybe it doesn't have permissions to them.



I have a 4.5.2 server and a 4.5.2 user tool. I do have the 5.1 user tool installed and have tried it as well. It has the same issues and furthermore, I have another Active Link that loads up the current user's name, manager, and department upon loading this form - and that doesn't work in the 5.1 tool. This worries me but since everyone here is using 4.5.2 for now, I am not concerning myself with it. It does make me wonder what will happen when we upgrade however.





---
Shannon B. Davis
Software Engineer - End User Applications
Boston Communications Group, Inc.
bcgi (781) 904-5328
sdavis@bcgi.net



You may also control your subscription options, including UNSUBSCRIBE, at http://www.ARSLIST.org This posting was submitted via the Web interface

You may also control your subscription options, including UNSUBSCRIBE, at http://www.ARSLIST.org This posting was submitted via the Web You may also control your subscription options, including UNSUBSCRIBE, at http://www.ARSLIST.org This posting was submitted via the Web interface interface