Question How to make such a SCANNER by making use of Access Database Table?

555access

Registered User.
Local time
Today, 17:27
Joined
May 22, 2012
Messages
10
How to make such a SCANNER by making use of Access Database Table?

A lot of stock market websites give us the ability for scanning the stocks which fulfill particular criteria / conditions etc. based on different parameters. Just as shown in these snapshots –



I want to make something similar for my personal offline use. I have already got the required data for all the fields in my access database in one single table itself.

What are the various options available for creating such a Scanner, either inside access itself or in any other 3rd party platform. Because if it is not possible to design something similar inside Access, then I am also open to the idea of using access data table as a back end and using any 3 rd party app as a front end if that can do this work very efficiently.

I hope that it will give me the ability to apply 10+ filters easily at one go, just by using the drop down type of feature, without having to switch back into the query design mode again and again for changing the filter parameters.

My current method of using a simple query in which I apply all these filters, is taking me a lot of time and effort, for changing the filter values again and again. So the current method is extremely inefficient. Therefor I am looking for an easier way to get the final query output data, which shows the filtered results and in which I can very easily change the filter conditions quickly.

Any ideas in this regard are welcome.

Thanks a lot
 

Attachments

  • Scanner 1.jpg
    Scanner 1.jpg
    101.7 KB · Views: 124
  • Scanner 2.png
    Scanner 2.png
    36.6 KB · Views: 135
My tendency with a lot of optional parameters is to build dynamic SQL, as demonstrated in the sample db here:

http://www.baldyweb.com/BuildSQL.htm

It doesn't have to drive a subform, it could open a report or whatever, just demonstrating the concept of building SQL based on selections.
 
My tendency with a lot of optional parameters is to build dynamic SQL, as demonstrated in the sample db here:

It doesn't have to drive a subform, it could open a report or whatever, just demonstrating the concept of building SQL based on selections.
Thanks pbaldy

Checking out the sample db.
 

Users who are viewing this thread

Back
Top Bottom