I have a function that creates a text file and need to run it from the data macro. so then the evens can use it on the table.
How do I go about doing this?
You don't, as per our chat. Data macros even run outside of MS Access, if they used code within MS Access, this could not happen. They are tied to the database engine, which knows nothing about Access front-end.
You can run queries from a data macro AFAIK, and it is possible to create a query to write to a file*, but you cannot run VBA.
* I looked into this a little more and I find: "Queries that contain linked tables, action queries, and database references are not allowed in data macros."
You can do this, but it not recommend. Remember, table triggers and store procedure code does run independent of VBA and in fact it runs even if you don't have Access installed.
However, assuming you going to be using Access to always edit the data (a reasonable assumption), then you can in fact have the table macro call VBA code. There are several ways of doing this, but the most common and useful is to set SetLocalVar to a VBA function. This has the added bonus of being able to pass some values to that function which in most cases is likely required.
So, keep in mind you can call VBA code, but then you are adding creating a dependence from your tables to VBA.
So just use SetLocalVar to some dummy var, and place the VBA function in the expression.
Related
I have an Access database with a few tables and several queries. I already have this working perfectly in Access but my boss wants me to replicate the results using excel 2010. I have tried using the MS query inbuilt into excel but I can’t get the SQL query to do the same thing, I have asked several experienced people but they also didn’t know. I have decided to try a different approach.
The users need to regularly update the information in the tables and then re-run the queries. The result is then exported to excel for further manipulation. Would it be possible for me to make the database accessible via runtime. Could I have it so that the user puts all the tables that need updating as excel spreadsheets in a certain folder and then in VBA in excel have the runtime access application update the tables, run the queries and output the results in excel? The main thing is that the users won't have the full access application.
I have had a look around but couldn’t find much on this. If not, any other ideas would be greatly welcome.
From the Access wiki:
The runtime version allows users to view, edit and delete data, along
with running queries, forms, reports, macros and VBA module code. The
runtime version does not allow users to change the design of Microsoft
Access tables, queries, forms, reports, macros or module code.
Therefore, you can send code to the Access runtime version that runs queries that update your data, and have Excel linked to the tables that result from those updates.
I have a very large amount of code written in VBA in Access .mdb files, containing forms and connecting to an Access data base. I need to migrate this code to a VB6 application. It isn't practical to rewrite all of it as there is just too much.
Is there a way to call that VBA file from a VB6 form with buttons, that would allow users to launch each one of these VBA modules, via a simple click on its corresponding button? What line of code in VB6, allows to launch a VBA file?
Update
I finally succeeded to figure out how to launch a VBA mdb file from my VB6 form using this instruction :
Call Shell("C:\Program Files (x86)\Microsoft Office\OFFICE11\MSACCESS.EXE C:\presto.mdb /runtime /cmd", 1)
So the VBA project is now launched from the VB6 form, but it crashes, at start up, showing this error "Runtime error ‘3024’ Could not find file ‘C:\db.mdb’".
I feel like I'm half way to thee solution. But I don't know what am I missing here?
Without knowing the structure of your VB6 application and your access files and what they do, it is virtually impossible to give any sort of useful answer.
What you want to do is not easily possible, as stated in comments VBA projects are not designed to work in this way.
However here are some suggestions.
Investigate the RunMacro command and see if this is of use to you.
You could try to use a tool like autohotkey to record mouse clicks where you want them and replay from your VB6 app.
Look at pulling out sections of VBA that are business logic and directly copy and paste code into your VB6 app. This may or may not work depending on the code.
Begin the slow process of rewriting (but don't rewrite in VB6, use VB.Net, C# or do a web app or something at least resembling a 2015 application).
If you want my honest advice begin to migrate to a more modern solution such as VB.NET so you won't have an even worse problem in 2020.
There is NO silver bullet for your problem.
It would be better to design a new form in VB6 with button as you said but also with some text(s)/list(s)/whatever(s) you want to display the results, then you copy/paste VBA code into button_click(s) event(s) to execute it and add to that vba code some output to the text(s)/list(s)/whatever(s) you decided to put on the VB6 form.
Edit : Ok, so taking your comment in consideration perhaps that trick could help avoiding re-write thousands of line code : add in the VBA code a while loop that trigger some Sub or Function on the presence of a flag on the system (a specific c:\temp\fileFlag.txt for example) so as soon as it appear the VBA code is called... if the VB6 control the flag would it do the job ? :)
I have a Microsoft Access MDB file on a website to which an ASP classic code adds rows.
How do I create a query/module that will run every time I add a row or automatically once a day?
If you're looking for something to run when a row is added, you're looking for "triggers" - which is not available in Access*. You find that sort of thing in proper RDBMSs like SQL Server, MySQL, etc.
If you're looking for something to run once a day, you could create a small VBS/PowerShell/etc. script and set up a scheduled task on the server to run it at an appropriate time.
You could also run the query in response to a page. If this is something that you want done after insert, then you can append the appropriate code to the end of the page or have it run as a part of the "success" page (if you have one).
* Unless you are using a .accdb (Access 2010 and later) file and the appropriate drivers. Then it appears you can use Event-Driven Data Macros to get the same effect. Thank you Gord Thompson.
What is the right way to do some calculation in MS access to be stored in the bound table through the user entry form
Should I make use of VBA or simply from access.
You can make simple calculations directly in a textbox for instance. If you set the control source to something like "=A*B", you will see the result of A * B in the textbox. However, in VBA you can write more complex functions that you can reuse (even from textboxes "=MyFunction(A,B)").
In VBA Functions you can store intermediate results in variables, perform loops and so on. You can even implement some error handling. This is not possible otherwise.
It makes your application easier to maintain, if you keep the code in a central place in modules, compared to spreading the calculations over dozens of controls in forms and reports.
The general rule is that you should not store calculations. If you must write a calculation to a bound textbox, you will have to use VBA. If you are using MS Access 2010, you can make use of calculated columns.
I would like to create an Access report in which the record source is created via ADO code and then set as the record source for the report when the report is run. The problem I am running into is how to add fields to the report since the recordset is bound to the report at run-time and not design time. Is there way I can manually add the field and make sure the field name matches what will be provided in the recordset field collection? Thank you.
The standard solution to this problem is to add all your fields in design view, up to the max available, and hide all of them, and show only the ones you need. Michael Kaplan explained that when he designed the Access Replication Conflict Resolver, this is the approach he used, precisely because adding controls at runtime quickly uses the lifetime limit on the number of controls on a form (700+, but I can't recall the exact number).
It's also just a bad idea, as #Jeff O says, to do design changes at runtime. For one, it means you can never distribute an MDE.
Several ways to do it, but all of them have their issues. create-dynamic report using vba
Other questions have found the folley in working in design mode programatically.