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,
Related
What’s the best practice for integrating SQL Server with Active Directory (AD)?
NB. I’m using SQL Server 2016
Crux of the issue: I'm using SSRS 2016 and have several reports that need to be filtered based on the user accessing the reports. Originally I created a table of users that would need to access the reports. Then in the report builder I passed the UserID as a parameter within the query so that the resulting dataset would be limited to the data the user needed to see.
The problem this created is that the User table would have to be maintained, and Active Directories are dynamic. Now that I have some time to develop a better option, I’d like to link the LDAP data with SQL Server.
I’m wondering what the best practice for doing this is.
One way I pursued this was through an SSIS package ADO.Net connection. Then convert the data. Then load it into a table. Then schedule a job to run the package however often I needed it. This was problematic because for whatever reason I couldn’t get the data conversion process to work.
The second way I’ve been approaching this is to create a linked server instance for the AD. My research has indicated that I’ll need to create a function that overcomes the string limitation of the xp_sprintf Function. Then leverage temp tables and loop through LDAP data to get around the 1000 record limitation from the AD. I've been able to accomplish all this.
At this point though, there appears to be some other issues.
This ultimately increases the code necessary in the views for my reports which may make it harder for other database users to update if & when the time comes. To the point that I'd need to abandon the views and create stored procedures for the reports to pull from.
This also increases transaction counts beyond the SQL Server to include LDAP every time a user accesses a report.
So to resolve that I could wrap the original query of the LDAP data to create a table and then create a job to run that stored procedure every so often.
Either option solves the problem of maintaining the users table which is good, but it isn't perfect because AD changes can take place at any time.
Which option is better here?
If the SSIS package is the better route, I’m curious as to why that is the better route. I’m not opposed to going back and figuring out what it is I’m missing on the SSIS package to make it work.
Are there additional options I should consider if I want to get the most up-to-date Active Directory listing?
Thanks.
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.
We have a large number of access databases that contain a number of common functions. We need to make a small change to one of the functions, and are looking for a way to automate this via scripting, etc. Is there any way to get at the VBA code inside an Access database, and make a change to it?
I have used ADOX before from PS or VBS to be able to list tables, views and queries, but it does not expose the VBA code in its API.
~bp
If the code changes are always in a module with a consistent name then you can simply remove the existing module and reimport the new version in all the projects you need to apply the change.
http://www.cpearson.com/excel/VBE.aspx
The above link posts information on how to import modules into a VBA project. So simple case of looping through your multiple databases and removing the module and importing the latest version.
If the code changes are located in different module names, you can open each database and loop through the modules to search for the string. The functions you'll need are listed here (depending on the style of change, it'll most likely be some combination of Find and ReplaceLine)
http://msdn.microsoft.com/en-us/library/office/aa223124%28v=office.11%29.aspx
I have multiple forms with specific buttons to show/hide data (f.e. data from last year/all data). I've been thinking a while about query performances and I can't really find a good source which explains how access handles those.
In particular I was wondering, if there is a performance difference between using a saved query (for a specific case, like 'data from last year') and appending parameters to a query during runtime (say add 'where xy = -1' to a query with no constraints). Will both querys be executed in the backend, or will any constraints I add to an existing query via VBA be executed in the frontend?
Should I create a query for every possible scenario or use only one query where I add parameters during runtime?
Fyi I'm using jet and my database is split to frontend and backend (Access 2007). The backend will be located on a network folder.
Check the answers to this question: does stored procedure enhance the performance in an acess databank,why?
Mostly covers what you are asking for.
As Access is a file based system rather than a dedicated server, absolutely nothing is run in the back-end, even if it is stored there, everything is executed locally in whichever copy you have open, namely the front-end or the back-end.
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,