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.
Related
I'm currently working on maintaining some old (new format .xlsx) excels with more than 60+ connections each that feed some various tables from a SqlServer.
I'm in search of some kind of toolkit, module, standalone script (or anything really) that let me bulk change the command text inside each connection properties.
The change should be not harder than changing part of the table name as the new table only contains the information that the table needs.
So far, the only thing that gets near what I need are those python modules but they don't appear to implement anything for handling connections.
Thank you in advance for any help you can provide.
With newly released Webi there's no way to manipulate reports with VBA like it was in DESKI era.
I'd like to know if there's a way for me to click a button with parameters in Excel sheet and get a report from the server?
I've been thinking of using the RESTful Web-services but it seems that there is a performance problem.
I also considered using a JAVA app in the middle using the SDK but it's not really satisfying as I add one layer.
Do you know if there's an other way to download a Webi report from and to Excel?
For this type of requirement, you'd normally use the OpenDocument feature. There is one thing that it won't do however, at least not for Webi documents, and that is deliver the output in Excel format (HTML and PDF are the two possible formats for Webi). In all fairness, the export to Excel option is only about two or three clicks away, but I can understand that this wouldn't be an ideal solution.
Another option is the Java SDK, which I would not recommend, as the ReBEAN SDK (the part of the Java SDK you need to interface with Webi documents) is deprecated and replaced by the REST SDK.
The REST SDK would be the way to go if the OpenDocument feature is not sufficient. Keep in mind that this would involve quite a few steps, each time sending a command to the WACS server and then decoding the answer. The steps would be:
Authenticate and get a logon token
Refresh the document (if necessary pass prompt values)
Export the document to Excel
Close the document
The REST interface is only supported on the WACS server, which should run on your BI4 server (unless you have a customised landscape). If it's slow, I would suggest looking into the root cause of this performance issue, instead of discarding the SDK altogether.
If you're going to use the REST interface, I would recommend opting for JSON to communicate through REST instead of XML. It's easier to read and parse.
A last option, which I wouldn't recommend, is LiveOffice. This is a separate product which allows you to embed contents from Webi documents into Office documents (most notably Excel). LiveOffice has always had its share of problems and has not received much love from SAP regarding much needed updates.
One final thought: the report will never appear in the same sheet, at least not without an additional amount of coding. Whatever SDK you end up choosing, you will always end up with an Excel file. If you want to show the results in the Excel file you started from, you'll need to code the steps to open the generated file, grab the contents and then copy those to your worksheet.
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 about to export a lot of data from a Lotus Notes db, and I'm wondering if anyone can shed any light on how exactly I can move forward on this point.
Notes has some views (lists with custom templates?) of some kind - are these saved in .nsf files on the Domino server, or are the .nsf files for email only?
If the .nsf files are actually the database files, what would be the best language / development pack to use to pull data from them?
If you need full-time synchronization between an existing Notes infrastructure and a RDBMS, LEI (Lotus Enterprise Integrator) or a third-party tool like Notrix would be your best bet -- it's as simple as defining a job and a schedule/trigger to run it. If you need to occasionally pull (or push) a subset of the data, then NotesSQL is probably the easiest approach. If you're not afraid of learning the structure of the NSF (Notes Storage Facility), then the LotusScript/COM API or the Java/CORBA API would give you finer-grained control.
If what you really need is a one-time dump of everything, then exporting all of the data notes to DXL (Domino XML) would give you the most complete version of the data you're going to get, and in a way that would let you recover and convert formatted Notes Rich Text, file attachments, and so on in a way that would be incredibly difficult to achieve otherwise. DXL is verbose, so don't say I didn't warn you, but it is pretty comprehensive as well. (The DOmino Designer Help entry on the NotesDXLExporter class has example code that is exactly on point.)
It all depends on what language you're familiar with.
If you know LotusScript well, then that would be my first choice since it's the most integrated with the platform.
If you don't know LotusScript that well, but you know C#/Java/C really well...then you shouldn't have any trouble using any of those APIs (and they should all be able to get the job done equally as well).
In Lotus Notes Domino all the data is stored in the .nsf files. This is true for all Notes databases, not just email. The data is all stored in documents which are basically collections of named fields containing values. The views are simply ways of indexing and displaying collections of documents based of specific criteria. The views can also calculate values based on the value of a field in the documents.
The Notes LotusScript and Java APIs are essentially identical and would be the simplest way to programmatically access the data. The C API is much lower level and probably overkill for this kind of thing.
You could look at NotesSQL, if you want to create an ODBC connection to an NSF file to pull data into SQL or Access. If all the data is contained within the view you could simply select all the documents and click Edit > Copy Selected As Table and paste into Excel.
To answer your other questions: Notes views are similar to SQL views - essentially a query on the data stored within the NSF. NSF files contain both the data and the structure of the application in one file.
My employer is considering installing OpenOffice.org's suite of Office products instead of using Microsoft Office. I've written several advanced applications in Access and Excel, and I'm trying to figure out what will and will not be compatable with OpenOffice.org.
Specifically, what do I need to do to have Calc (OpenOffice.org's version of Excel) read and execute VBA in macro's and tie macro events to button clicks?
Also of note, I'm using the MySQL Connector from within Excel to dynamically update data in the spreadsheet. What might I need to do to preserve data connectivity to our MySQL server?
Thanks
As far as I know, OOo Base can connect to an mdb file to the extent that it can open tables and queries. I think anything else - forms, reqportes, macros VBA and native - would need to be redeveloped.
I don't believe that OOo Calc can read or execute VBA: it has its own dialect of Basic, which has a variant syntax. It doesn't, as far as I can tell, support the concept of Class, for example. Some work appears to be occurring, however, see the OpenOffice Wiki for more information. Right now, I'd say you should be planning on a careful and complete rewrite.
Regarding the MySQL connector - I'd say that's the least of your worries...
On the plus side, you're likely to have real job security for a year or two while you get everything ported!
I recently discoverd go-oo which seems to be able to achieve your task.