I would like to know if it's possible to read data from an Excel spreadsheet used as database with Visual Basic for application (The IDE included in Microsoft Excel). I know it's possible with Visual Basic Studio but I don't know if it's possible using the Visual Basic IDE integrated in microsoft Excel.
Basically what I want to do is to create and authentification system this way (The spreadsheet will haw 3 columns : ID, Login and Password).
I will not be surprised if you tell me that using an Excel file as a databse is not the best practice but it is imposed to me and I must do it this way.
Thanks in advance for your help.
You can use it as a database. You can either call it with MS Query or open your dataset (invisibly) for reading. MS Query has the downside of considering values invalid at times.
Related
I have a few SAS programs that I need to run from excel. The programs pull tables from SQL, perfom some calculations and give an output table that I would like to present in Excel. So I figured that it would be great to run everything in excel.
There are a few parameters in the code that need to be changed before running, so the best idea I had is to put the SAS scripts in cells on an excel sheet and change the variables with VBA.
My question is, is this achievable? Can I connect to SAS and do everything from excel?
I'm fairly good with VBA, starting to learn SAS, but I don't really know how to connect the two. Thank you for your help!
Yes it is possible , i did this in my work a week ago , SAS have an documentation here?
The link below can help you.
http://documentation.sas.com/api/docsets/itechwcdg/9.4/content/itechwcdg.pdf?locale=en
You can use ADODB to connect to , see here for the strings
https://www.connectionstrings.com/sas/
Your options are:
1) use VBA to connect to IOM, create a workspace, run your program.
This requires quite a bit of VBA, as well as the SAS Addin for MSO, and various components.
2) Run a Stored Process (STP) via point and click using the MSO addin
Again, this requires a desktop SAS Addin deployment, and isn't scriptable with VBA
3) Run a Stored Process as a web query
This is an excellent option - you don't need any special desktop installation, you can easily add (url) parameters, you can use it with / without VBA, and your output will render easily into your worksheet so long as you stream tab delimited data via the _webout fileref (without %stpxxx macros). It will also work with all versions of excel and SAS.
This approach is described here: https://www.rawsas.com/sas-as-a-service-an-easy-way-to-get-sas-into-excel-power-bi-and-000s-of-other-tools-languages/
Is there any way of reading excel data in ASP.NET Core (built over .Net Core)? I am not able to refer OleDB in project.json of my .net core project. Is there any other way of doing this?
Do you really need OleDB to read Excel today? To my opinion, OleDB is a bit outdated. There are opensource libraries to work with Excel files which are much easier to use and provide a lot of flexibility.
ClosedXML (https://closedxml.codeplex.com/) is one such library. It's well documented and allows to both read and write Excel files with custom cell style formatting.
I have used OleDB for reading very large Excel files too, it works but there are certain issues with it, here are a few of them off the top of my head:
You will need to install MS ACE OLEDB provider which sometimes is hard to configure.
You will have to read Excel files in passes while with ClosedXML you can access rows/cells randomly by id/address.
OleDB uses a Windows registry configurable setting to check the number of rows (default is 8) to determine the data type for the whole column and sometimes there are issues with it because the data type is determined incorrectly. ClosedXML allows you to set a specific data type for any cell.
I'm not a ClosedXML developer, so this is not an ad. As I mentioned, I have used (and continue to use) both OleDB and ClosedXML in my projects. With OleDB I was able to read very large Excel files (400-800K+ of rows for example) either row by row or using SQL Server "SELECT * FROM OPENROWSET(...)". Also SQL Server can directly write to Excel files using same ACE provider and it worked for very large files too.
However, ClosedXML I have used for reading/writing relatively small files but they used a lot of custom formatting. So if you start a new project I would recommend going away from OleDB.
The only limitation of ClosedXML is that it support only zipped XML Excel files, i.e. Excel version 2007+. You can find many examples on the ClosedXML site mentioned above which would help you to get started.
Let me know if this was helpful. Thanks.
As indicated by andrews, it is recommended to use a third-party library, especially when working with formatting. An alternative to ClosedXML is EPPlus. For most of my project I have used ClosedXML, but I had to switch to EPPlus because it has support for charts.
For ASP.NET Core, you can use EPPlus.Core. I have performed a quick test within an ASP.NET Core 2.0 console app and it seems to work fine:
var newFile = new FileInfo("some file.xlsx");
using (ExcelPackage xlPackage = new ExcelPackage(newFile))
{
var ws = xlPackage.Workbook.Worksheets.Add("etc");
ws.Cells[1, 1].Value = "test";
// do work here
xlPackage.Save();
}
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.
I have a system with an Excel spreadsheet template file which is used for invoicing. I would like the user to be able to click a button on an Xpage, which will then open the spreadsheet and enter the latest invoicing data in Excel. I don't mind if Excel is either the application on their machine or on the server, but my preference would be the application locally on their machine.
I've looked into Xagents, as I feel this is probably the answer. I know they can be used to create Excel but I have not been able to locate any mention of opening an Excel file, and entering data into specific cells.
Is this possible?
EDIT: you can use Apache POI for editing and creating Microsoft Office documents. This is a java project which gives you a handle to office documents and this can be used using java.
A good starting point can be the blog of Christian Guedemann from webgate:
http://guedebyte.wordpress.com/2012/09/17/documents-and-spreadsheets-with-xpages-building-the-kernel-part-ii/
(end of edit)
The only way I KNOW and tried to write data from Notes to Excel is exporting the data to an HTML page and setting the Content Type accordingly (e. g. as described here (there are a lot more resources available for taht):
http://www.dominoguru.com/pages/developer2010_xpagexlsexport.html
I am not sure if this is of help but it seems that this project can help you:
http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=ZK%20Spreadsheet%20for%20XPages
As far as I can see this project can load Excel files from XPages - and then it should also be possible to edit the files.
Besides that the only solution I can think of is a Notes Agent that is called from the XPage. This agent can then run in background and do all the excel stuff. After running, the XPage can show a link to the Excel file. Actually this is the solution I would consider to implement - but maybe others step in with better answers here.
You don't want to introduce a dependency on Excel in your application -- wouldn't work with an iPad front-end. Rather have a look at the ZK Spreadsheet, it will fulfill your needs.
However if you have to have Excel, then you need a roundtrip solution: load the Excel from an URL (probably generated by an XAgent (?) and save it back. The saving back part is the tricky one. Normal HTTP doesn't allow that. What you need there is a webDAV capable server. Watch out for a project on OpenNTF soon (just clearing IBM legal) that provides webDAV.
However the ZK Spreadsheet looks much better for your needs.
I have a sample database at the following URL --> http://www.nnsu.com/nnsusite.nsf/%24%24OpenDominoDocument.xsp?documentId=B65507CB2DE15B3286257986005F061D&action=openDocument
Download the APCC.nsf. This will allow you to create/read a new EXCEL spreadsheet and then stream the resulting file to the requesting browser. There is not need to have EXCEL or office installed on the Server.
THe examples create a new workbook, but you can also store a "template" on the server or in a notes document and use it as a starting point and then save it to a document or stream it to the requesting browser.
With Apache POI you can read/write to a spreadsheet using data from the notes document the process is initiated from.
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.