I am trying to build a user interface which will allow users to choose what kind of information they want, then based on these selected conditions, I need to query an access database and retrieve the corresponding data for future calculation. During calculation, there are two additional tables that I will query from. Finally, I need to display the calculated results to users. Now I have some questions:
Which one will be easier if I use excel as a front-end to users and retrieve querying data from Access to excel vs. I use access forms as a front-end to users and directly work with access to query data?
Does access forms can perform functions like allow users to select options from a drop down list? and once options selected, Access will query the target info?
Can Access perform intermediate calculation for large amount records? Will it get very slow? Compared to excel, which one is better in terms of calculation?
I never use Access before and just know a little about Excel VBA, not totally familiar with it, not to mention object models. So, in this case, which way is time-saving for me? or they are probably the same time-consuming?
Anything else that I should be aware of?
Thanks so much!
Bing
Definitely Access - it is specifically made for working with, querying, and reporting on data. The language of VBA that you have experience with in Excel is the exact same language used for coding in MS Access!
Access, no question!
Absolutely. Of course it doesn't magically know this as your requirement. You have to drop the combo box on the form yourself, and then in the OnChange event of the combo box, alter a query statement that displays results to filter based on the user's selection.
Sure. Make a temp table (a table that is only used for the calculation), populate the records with INSERT statements, apply intermediate calculations with UPDATE statements, and display the results. Access is built for this kind of thing and will most likely be faster than Excel.
Access uses VBA as well. There may be a larger learning curve to switch, but if you are familiar with the user interface objects in Excel such as Button, Combo Box, etc., they will be very similar and yet more intuitive in Access (Because that's what Access was made for)
Access has some quirks. Google a few tutorials and get some background on the ways Access is traditionally used for your kinds of scenarios and it will go a long way toward streamlining your development.
Start with the simplest model that will accomplish what your requirements are, and implement it. Then work through the quirks and bugs that you find with Google as your friend, and you should be able to get something solid pretty quickly! As you get into the experience, feel free to post new questions with specific problems you find along the way.
Best Regards,
Related
I have reviewed the previous Questions and haven't found the answer to the following question,
Is there a Database Tool available in MS Access to run and identify the Queries that are NOT Bring used as a part of my database. We have lots of Queries that are no longer used and I need to clean the database and get rid of these Queries.
Access does have a built in “dependency” feature. The result is a VERY nice tree-view of those dependencies, and you can even launch such objects using that treeview of your application to “navigate” the application so to speak.
The option is found under database tools and is appropriately called Object Dependencies.
The result looks like this:
While you don't want to use auto correct, this feature will force on track changes. If this is a large application, then on first run a significant delay will occur. After that, the results can be viewed instantly. So, most developers still turn off track name autocorrect (often referred to track auto destroy). However, the track auto correct is required for this feature.
And, unfortunately, you have to go query by query, but at least it will display dependences for each query - (forms, or reports). However, VBA code that creates SQL on the fly and uses such queries? Well, it will not catch that case. So, at the end of the day, deleting a query may well still be used in code, and if that code creates SQL on the fly (as at LOT of VBA code does, then you can never really be sure that the query is not not used some place in the application.
So, the dependency checker can easy determine if another query, another form/sub form, or report uses that query. So dependency checker does a rather nice job.
However, VBA code is a different matter, and how VBA code runs and does things cannot be determined until such time code is actually run. In effect, a dependency checker would have to actually run the VBA code, and even then, sometimes code will make several choices as to which query to run, or use - and that is determined by code. I suppose that you could do a quick "search", since a search is global for VBA (all code in modules, reports and forms can be searched). This would find most uses of the query, but not in all cases since as noted VBA code often can and does create sql on the fly.
I have a vague recollection part of Access Analyzer from FMS Inc has this functionality built in.
Failing that, I can see 2 options that may work.
Firstly, you could use the inbuilt Database Documenter. This creates a report that you can export to Excel. You would then need to import this into the database, and write some code that loops the queries to see if they appear in this table;
Alternatively, you could use the undocumented "SaveAsText" feature to loop all Forms/Reports/Macros/Modules in your database, as well as looping the Querydefs and saving their SQL into a text file. You would then write some VBA to loop the queries, open each of the text files and check for the existence of the query.
Either way, rather than just deleting any unused queries, rename then to something like "old_Query", and leave them for a month or so in the database just in case!!
Regards,
I am new to Access 2013. I have a warehouse management project to create with Access - many users at the same time from different locations.
I have a couple of basic questions, if you don't mind.
Is it better to code using only macros or is VBA the preferred choice? Or is a combination a better approach? If so, what sort of functions would you code in each modality?
The next question has to do with data entry. We are going to be using bar-code scanners in a few locations.
I would like the terminal or the wireless receiver to be in ready mode all the time for the next scan, which of course happens at random times throughout the day.
I assume I would create a loop that stopped at a point that called for input into a text box. How would I keep the program 'active' letting the operators just scan without them having to refresh anything.
Hope the questions aren't too vague or elementary.
Some thoughts:
many users at the same time from different locations
You should create a database-only file for storage and a front-end in another .accdb file. That's the best -- or only -- way to get multiple users without problems.
Is it better to code using only macros or is VBA the preferred choice? Or is a combination a better approach?
I would always go for VBA because of flexibility, but that also requires more knowledge of what you're doing.
I assume I would create a loop that stopped at a point that called for input into a text box. How would I keep the program 'active' letting the operators just scan without them having to refresh anything.
I'm not sure if that's the best approach in performance, but your idea is somewhat correct. You can use a loop that in the end of every iteration calls DoEvents to allow everything else to run. Otherwise your database will simply freeze. I'm not a big fan of that idea, though.
Some additions to what Paulo wrote:
I don't know how many "many users" are, but if it's more than a few, you should think about using Sql Server Express (the free version) as backend instead of an Access file. It is much more robust. And if "different locations" means that WAN connections will be involved, you can get away with much lower bandwidth requirements than with an Access backend.
Don't even think about macros, use VBA. One of many reasons is that you can find lots of help for VBA (here and elsewhere), but not for macros.
AFAIK, bar-code scanners basically behave like a keyboard - they send the text/numbers they scan as if it were entered by hand. If the Textbox has the focus to receive the input, you can react to the AfterUpdate or OnChange event of the Textbox, no need for an endless loop.
I am working on project in economy where I need to manage large data in linked tables, with many foreign keys.
I have a few years of experience as Oracle DBA so I can manage all that without problem,
But I need to be able to share the data with others that have no knowledge in databasing,
There for I need to get them some graphic way to show the data.
Toad does all what I need and much more, but the program is too complicated for my needs.
Instead of wasting time on writing a program in C# that manages the data, I am looking for a good program that:
Shows Main table/view data with option to filter/group/order with drop-box options
Selects a row and shows data in linked tables by the selected row's data
Makes report/data pages of my selected rows that I can adjust and print. (I know it's a bigger request)
In Addition, what is the most fit and easy DB for it? I worked only with Oracle but it's sure too much for that, so MySql? Access (I tried first to do all that in Access program but It's just too hard to adjust forms and so, and in the end you cannot make a publish version.
And the tables will be with start_date and finish_date that follow each other for same ID,
But I don't think it will be a problem that I can maximum make view that shows only the last one. (BTW, what is the name of such table, I never knew that)
Take a look at Tableau http://www.tableausoftware.com
It will let users view the data many different ways, makes great visualizations and works with most databases. It's a read-only tool, so it's perfect for safe reporting, but you'll need to couple it with something else if you want your users to make changes to the data.
You can define a connection in Tableau that sets up the relationships for users that don't understand foreign keys and the like. Or make views that hide those details, of course, regardless of the tool you choose.
Does anyone have any pointers on how to go about creating a "wizard interface" using Access 2010? I need a sequential set of forms that will be capable of branching the flow based on answers from the user and data found in the database. I have used Access before for some CRUD/Reports type of applications, but in this case I can't seem to wrap my head around how to get started on such a complex machine.
Before anyone suggests it, I cannot use anything but Access due to client requirements.
I feel your pain ... working with Access gets so difficult where there are complex requirements.
Gather and document the requirements
Make sure you've teased out every possible wrinkle and contingency from the client, and put it into a flow chart or something.
Extract the models
Figure out what models are being used -- customers, addresses, vendors, products, etc. These will have to be created as tables or adapted to existing ones.
Extract other variables
What could potentially change over time and/or what will the client want to be able to change via an admin screen? You'll have to decide which of these variables to put into tables, and which are ok in the code (form logic and/or VBA).
Design the tables for the wizard views
I imagine you'll want a wizard screens table, where each row corresponds to a step; each should have (other than an id column) a previous screen column, and a form name or form template name column. You'll need a second table choices with a many-to-one foreign key linking back to screens; each row here will correspond to a possible outcome of the view, and the target next step in the wizard.
Design the forms
Finally, design the forms corresponding to each wizard step or template, pulling data from the structures in 1-4 as needed.
I'm trying to split a database into two pieces -- a backend that updates automatically, and a front-end that allows searching and adding/editing comments. The data in the source database is pulled together from multiple tables into a pair of queries, and I want to use these queries as the source of the current database.
Access 2007 supports splitting a database into multiple pieces, but not in the way I'm looking for. It keeps the tables in the source database and puts all the forms, queries, reports, and macros into the new database. The tables and queries are already in the back-end, and this new database should just provide a good GUI to the end-user.
Access 2007 also supports linked tables, but these can only use a table as a source, not a query object.
I was thinking that the best way to do this would be to do a SQL query along the lines of
SELECT * FROM SourceQuery IN "C:\Path\To\ExternalDB.accdb";
Is what I'm working towards even possible, and would this be the best way to do it?
Since its still relatively early in the project, rearchitecting the database isn't out of the question, but is something I'd prefer to avoid.
You described the usual Access BE-FE division correctly: only tables in the back-end. I'm aware not all DB programs do it that way, but this is Access and my approach would be to honor the usual division. (And you hardly have a choice in that you can't "link to a query" in Access.)
Reviewing your comment ('There is a specific reason ...'), I think this would possibly mean
adding a few more tables to the back-end, essentially buckets (import-data in ready form; export 1; export 2) that allow all users to get to consistent processed data;
making a small admin FE that sits next to the BE and stores your modules, queries for export, and export routines; and
having some redundant queries on the user FE. This is vexing in my own work. I just try to design sturdy stable "building block" queries in those roles, and keep their number to a minimum.
Hope I'm understanding you correctly, but the most sensible solution would be to link the tables in the backend DB and copy the queries to the UI database. Those queries would still be able to access the uderlying tables (via the linked tables) without issues and would be accessible through normal means to your forms and VBA code.
Is there a particular reason you don't want the queries in the UI database?