I want to be able to use the Sendwait function to automate a MS-ACCESS application using powershell commands. Unfortunately I haven't been able to get a handle in the usual way to the actual application window. I can get a handle to MS-ACCESS itself, but attempts using Sendwait to automate the window failed.
Any reason why you need to send keys? Why not just use the methods and properties of the object in question.
Just go:
To launch Access, open a database, and then print a report, and then quit?
$Acc = New-Object –com Access.Application
$Acc.OpenCurrentDataBase("c:\t.accdb")
$Acc.docmd.OpenReport("rptCustomers")
$Acc.Quit()
So most if not all methods and properties of the Access application can be used via power-shell, and as a result, I don't think you need nor want to attempt using some type of send keys as that tends to be rather flakey and a poor way to automate things. You might want to point out what commands or what you require, but you can also call VBA code this way, and as noted, even add records etc.
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,
This is probably a noob question, so I apologize in advance.
The HBase console, as far as I understand, is an extension (or a script running over) JIRB. Also, it comes with several HBase-specific commands, one of which is 'get' - to retrieve columns\values from a table.
However, it seems like 'get' only writes to screen and doesn't output values at all.
Is there any native hbase console command which will allow me to retrieve a value (e.g. a set of rows\columns), put them into a variable and retrieve their values?
Thanks
No, there is not a native console command in 0.92. If you dig into the source code, there is a class Hbase::Table that could be used to do what you want. I believe this is going to be more exposed in 0.96. At this point, I have resorted to adding my own Ruby to my shell to handle a variety of common tasks (like using SingleColumnValueFilters on scans).
I am looking for a solution to effectively communicate between two running MS Access applications.
The approaches I tried so far is to use a common linked table and to use MSMQ service for communication. Both approaches work, but there is no way to "push" the data or command from one application to another and since MS Access doesn't support multi-threaded execution of VBA code, it is very difficult to implement polling without performance disadvantages.
Same time, VBA does support the addressof operator (from version 2000) that means we can also theoretically implement call-back functions in VBA and MS Access. But I have never seen any example how this can be used for inter-process communication and would appreciate any minimal example how I can send a string from one MS Access application to another without monitoring a shared table all the time.
You can use GetObject() to return the Access.Application object from another running db. With the application object you have access to just about everything you might need. Here's a contrived example of opening a form (but you can do a myriad of other things with the Application object):
Sub TestInterop()
Const mdbPath As String = "C:\OtherApp.mdb"
Dim OtherApp As Access.Application
Set OtherApp = GetObject(mdbPath)
OtherApp.Visible = True
OtherApp.DoCmd.OpenForm "Accounts"
End Sub
If the program is not already running, the GetObject() call will start the application (you would need to be careful if you have multiple versions of Access installed as it's difficult to know at runtime which version would actually open the .mdb). However, if GetObject() needs to start the app, it will do so with the visibility set to False, so we explicitly set it to True. If the app is already running, setting its Visibility to True will have no effect.
Consider it a wild idea, but may be put all your tables into sql express and/or sql ce and make look like a frontend to those tables?
Hey guys I've written a little module/macro that helps our inventory department, they will need to run the module/macro a few times every month. They receive the databases from out in the field these are exported from some 3rd party inventory tracking system we have.
My question, is there any way to install this module/macro outside of the db file but still within access so that the inventory management team does not have to open vb editor, import the module, create a new macro, name it, set it up properly to execute the function?
The module/macro does not need to be changed for any new database that comes in.
Basically they need to be able to open any database received by the field and have this functionality in the module/macro available to them without having to set this. Is this possible?
You could look at my article for vb123.com:
Using Database Library Files in Your Access Application
The thinking there is that you can put access objects in a library file (still an mdb or mde file, or any of the new access file types) and then by just adding a reference to the file in your VBE project, you get that functionality made available to you.
It works with forms, reports, queries, classes, etc. To be honest, I haven't tried it with macros, but don't see a reason why it wouldn't work.
The beauty is that reusable functionality is packaged into one file, that is still just a plain old access file.
If you had the inclination, you could also write an access add in that basically calls your macro in the library.
We did this with a product for making dealing with SQL much easier in Access, and it has worked for years with Access installations all over the world. You can install the add in using a professional installation package such as wise installation, making it a pretty seamless experience for the end user of your macro. However, there is a considerable overhead in writing this kind of setup in a professional way. Depends on what your users need, I suppose.
Perhaps you are thinking of VBScript or a back-end, front-end set up?
You can use VBScript to perform actions on an Access database, through the Access object, with ADO and so on. The script can either accept command line input, request information, or run against any database in the current directory.
With back-end front-end, the new database becomes the back-end and the Access file with your macro is the front-end. Your macro should ask the user for the name of the back-end file and either use that with the Access object or link the tables, according to what is needed to be done.
I have used Access 2003 to develop a frontend to a SQL Server database. Because the system was intended to use different Schemas to partition the table data, an Access Project did not work. So, instead, I am forced to take over the connection management for access - I maintain a global connection object, and assign recordsets to Forms rather than recordsources.
One issue this causes - any time someone tries to use built-in Access functionality that interacts with the recordset, the operation doesn't work, and a dialog box is displayed saying 'Data Provider could not be initialised'. I've done some research, and have been unable to find a relevant cause for this, but I suspect it's due to Access expecting a Form to have a proper recordsource property, and does not really work with assigned recordsets.
Anyone able to shed any more light on this one? Is there a way to use self-managed recordsets, AND make use of built-in functionality? Can anyone confirm this is an Access bug?
After some playing around, I found a partial solution. I was using Client-side cursors, but leaving the recordsets connected. By instead disconnecting the recordsets, the Data Provider messages went away. Of course, that introduced other issues, but that's another story...and of course, I still don't understand WHY doing this made a difference...anyone else?