I have a single entry output from a paradox table which is imported into Access. Now I have created a report and done the databinding within the report to the dataset from Paradox. When work is done in Paradox the single entry output changes...
How do I open up access and have the values from the report update automatically without having to reimport the table manually?
The objective is that when access is opened the report comes up immediately for inspection before printing.
Use a linked table instead of importing the data (assumes a provider for paradox is available, which seems likely).
Linking directly to the Paradox table should work. The way to do what you asked, automating the import, would be to run DoCmd.TransferDatabase in either an autoexec macro or in the OnLoad event of your report. You would probably want to start with a delete query to reset the table too.
Link table to Paradox file through GetData on menu. You select the file from the route directory where your db files are and select. Maintain a link and bind the date relationships to the dataset. As you update using the Paradox database the tables in Access will update also. You musn't run the db and access the same time otherwise jet engine won't work.
From the design view of the report, go to the property sheet and the Event tab. Find the On Load event and click the elipsis button. Select Code Builder if presented with the Choose Builder dialog. This will drop you into the VBA editor in the Report_Load event. Edit to look something like this:
Private Sub Report_Load()
DoCmd.TransferDatabase acImport, "Paradox 7.x", "c:\yourdata\yourfile.tbl", acTable, "SourceTable", "YourAccessTable"
End Sub
I'm not sure on the specifics for the Paradox version, the file naming convention, etc. (I only dabbled with Paradox briefly and don't remember it's specifics). Watch the intellisense or put the cursor on TransferData and press F1 to get the Help for the TransferDatabase method for reference.
Ahead of the TrasferDatabase statement you might want to run something like:
CurrentDb.Execute "DELETE FROM TableName"
That will blow out the destination table on the Access side ahead of the load from the Paradox side.
Related
`Recently, I was given a task to automate the process of inserting some data of an ECU in CANoe into an already existing Excel sheet using CAPL. I am fairly new to this and wanted some help. I will be as elaborate as possible.
How can I create an link an env var to a database in CAPL/CANoe.
I have already creaed a panel with a button that should be assigend with the above asked env var. So, my question here is how can I access an already existing file that needs some data from this button? I mean CAPL does not allow excel format. How can I output some data to an existing excel sheet with the click of a button? How should I proceed to write the code for this?
CAPL has no API to communicate with Excel and/or print to Excel format.
You need to write your library to do it, or use an external script (think a python script, or something else) with a call to SysExec() in your CAPL.
To the best of my knowledge, there isn't an opensource solution ready.
I am relatively new to VBA and I need a solution to a problem I have.
Currently I have two excel documents - one which is a form where the user enters data and this is then sent to a second document which acts as a database for this information. My issue is that when people are looking in the database data cannot be sent to the second document because it is open and there are overwrite errors.
It is my intention to have the databases location hidden away within a network drive so it cannot be found meaning the only way to access I is through a button on the first document.
Is there a way that when the open button is pressed to access the database that a copy of the document is opened instead of the actual document itself so data can still be sent?
So, you have a few options here:
a) Use an actual database. Not so much to solve this specific problem (that too) but also because making a "database" in excel is usually a terrible idea in the long run. But I know that is not always possible, and it's overkill in many situations so...
b) Have that "database" workbook set as "Shared Workbook". Shared Workbooks come with their own host of issues (namely, can't edit certain aspects like the VBA in them, conditional formatting, and others). But if it's strictly for reading and writing data, it can work. It also comes with its own version control, so that's good.
c) What you originally asked. It is quite simple really, as you said, you make a copy of the document, ideally in one of the user's local folders . You can do this using FSO (see VBA to copy a file from one directory to another)
The only issue with this last approach is that you need some way to track when the user has closed that temporary file, in order to delete it (if you absolutely don't want to leave any traces). Otherwise, you can just leave it, and overwrite that same file each time the user presses the "View Database" button.
We have an application to track work orders (hundreds of thousands) built on an Oracle database. Data entry is cumbersome and report features non-existent. IT is inflexible. We do not get support from that end. Accordingly, users have created Excel "tools" to run queries and make sense of data using ADO or ODBC connections.
What we also need is a way to record comments on specific work order (WO) records and have those comments travel with those records somehow. There are multiple users using their own spreadsheets, all querying the same database.
I'm envisioning a junction-table approach, perhaps using Access, where some VBA could take a users comment from the row in the worksheet, capture the WO number, user id, date, and comment text and store it in an Access table. Those fields could then be retrieved by some more code. This would allow any user to see all comments by any other user related to a specific WO.
I'd greatly appreciate feedback ... on the practicality, preferable constructive, but brutally honest is ok too.
Much thanks,
Kevin
Apart from this being a horrible mess you could:
use SQL Server instead of access - you can get a free copy that will probably cater for your needs. Access will also work, but it is bodge. SQL server is more professional!
I would avoid doing data entry in excel. You could build a front end (possibly in Access with SQL Server backend) that allows data entry. You could add pretty simple code to all your workbooks, which will probably reference code that will be in an excel addin. The addin has code to simply open an access database, open a form and find the WO that the user was viewing in excel.
2a. Or you could use an excel addin with a data entry form, to do data entry, but beware managing the locking, refreshing and update of displayed data.
Creating excel addins is easy, (re-)distributing them is easy, access (or whatever front end you use) is designed to do record management (ie lock and update or lock and cancel or just view) etc.... Plus you want to avoid addinghte same or similar code to all your workbooks.
Each users workbook would have very simple code. Just to tell the addin what WO you want to operate on.
Do you have sharepoint? If so Access 2013 can deliver forms as webpages - very easily, so you might not even have to manage a front end access file.
Happier now?
For those that may stumble on this post, what we ended up doing was use VBA to store comments in a separate SQL database. Users double click the cell with the WO number to get an input form prompting for comments with options to add new, append or remove existing. Entries are passed to the SQL db and also to columns in the worksheet so users can see all the entries. Time stamp/Network ID provides when/who provided comment. Existing comments are fetched when users re-open file. Works great.
I'm trying to wrap my head around it. I've checked other questions and nothing seems to be too similar.
The Office 2013 development centre contains extensive DAO examples and states it is one of the easiest ways to work with an Access file (does not require an Access window) but DAO is a deprecated technology. (https://msdn.microsoft.com/en-us/library/office/ff834801.aspx)
I'm trying to write an Excel Add-in (eventual end point) that will grade Access assignments in .accdb format.
I'm can't just use ADODB to perform SQL queries to extract data, unless SQL can also do the following:
check a specified report has a specified title
check that specified tables, queries, forms, and reports exist
check specific fields in a table exist
check that specific fields have been set as the Primary Key
I also need to check that certain values exist in a table, but those I can solve with SQL.
So should I be using DAO or stick with ADODB? Remember, I'm using Excel, not programming in Access VBA.
The simplest way to work with excel tables is to link them in Access either manually or via the TransferSpreadsheet function in VBA. If you use a generic naming standard for the file names and tab names in Excel, you will not have to relink, rather you can replace the Excel file and the Access link will read the new file unless the layout has changed.
Once linked you can use the query-by-example tool to write your queries which also can be written into code (i.e. either embedded in the VBA [old school and not a best practice] or saved in an Access table then looked up and assigned to a variable for use with the CurrentDb.Execute strSQL, dbFailOnError command.
I suggest manually linking the first go round so you can manually define the individual column types vs. letting Access mess it up.
If you cannot use generic names and have to pick the file via a browse dialog, you can get a file browse function via Google to allow you to programatically link the file. (or you can rename it to a generic name which works even better)
So DAO vs. ADODB is moot from an Access perspective. I supported 50 databases with 70,000+ lines of code and dozens of Excel source files the past 4 years and never had to ponder the question.
Microsoft originally deprecated DAO in favor of ADO, but recently renamed DAO to Microsoft Access Engine (ACE) and is now pushing it as the preferred data access technology for Automation-supported environments (VBA, WSH etc.)
In general, in your scenario I don't think it makes much of a difference which one you use. I suggest you read through this.
I don't think it's possible to read table/query/field information via SQL. However, this can be done either with the DAO.TableDefs and DAO.QueryDefs collection, or the ADO.OpenSchema method.
RE: forms/reports - I don't know if it's possible to read form/report information via DAO or ADO even without SQL, as it is actually part of the UI objects, and not the data; unless we're talking about reading/parsing the system tables. You may have to open the database in a hidden Access instance and read the forms/reports that way.
I have an SSIS (super)package that consists of several (about) 40 packages, each of which has several data flow tasks, most of them loading some excel data to a sqlserver database. So I have several excel source connection managers, one per excel file.
This has always worked fine until recently : I have to change an excel source in one of my packages (a column was added in the excel which has to be loaded in the destination sqlserver table) but I cannot edit the excel source in SSIS : when I click on "columns" I get an error box "DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER". So this is a design time issue, not a run time problem. I've seen a question like this one on stackoverflow but no answer. Anyone has an idea ?
I' ve already removed office 2007 and reinstalled office 2003 on my machine, but this didn't help
it has nothing to do with 64bit mode, which I've read about here
Is there some limit on the number of connection managers in ssis ?
Most of my connection managers were created with copy/paste and hence they have the same Id, although they point to different excel files. Could this be a problem ?
I should also mention that the package runs without any problems, so it's only "editing/changing" the package that doesn't work. For the moment I circumvent this problem by disabling the data flow that should change and by replacing it with a sql statement that hardcoded inserts the data from the excel into the destination table.
Maybe another intersting thing to mention : I can create a new package and add and change excel sources without problems, but then again, when I try to copy this excel source in my package, I cannot edit it.
Did you try to check the advanced options on the Source Connection?
Right click on the component and select "Show Advanced Editor..."
Select the column mappings tab and press the Refresh button.
This should point out that the XLS connection has some additional columns or that the file that you are pointing at, cannot be pre-validated at runtime.
M.
I'm not sure if this will work but try the Work Offline option in the SSIS menu in BIDS/VS. What this should do is not validate the connection before you edit the component. It might be able to get you into the component.