in term of performance speed comparsion and without consider the development time
is that Excel VBA always faster than Apache POI when perform same task?
e.g. - fill background color/font formatting
- convert csv into excel file
As I hear people smarter than me say all the time: it depends. You will have to go through some testing yourself to see what gives you the best performance for the tasks you want to accomplish.
If I would have to guess than I'd go for VBA. Chances are you'll be able to do much more than is available in POI too. The choice in the end will also be influenced by experience and architecture and ...
Related
I am looking at ways to bring an Excel Spreadsheet, which uses lots of Visual Basic Access code - onto the Power Platform. The purpose of it to do Forecasting and Optimisation algotithms.
What is the best way to re-create this code?
I am thinking that we move all the data from the spreadsheet into Dataverse. It seems the only option to run the code is to put it into an Azure Function?
Is there a way to do this another way, through AI Builder or Power Automate? Could this be ran through Power Fx - or is Power Fx limited to basic instructions?
It seems limited in the way we can run code through Power Platform... any help or advice is appreciated.
Todd
I dont think a 1:1 copy paste action is possible (because of that VB access code).
Although Dataverse is a relational database it supports most common database functionalities. And if it is simple data (and not too much of it) you could alternatively use SharePoint lists. This is often simpler, and less expensive in licenses.
Also Power Automate can be used for automatically updating data in DV or Lists.
So if you manage to get you data into on of these two, the "Power Platform way" would be to expose it using Power BI.
It can be a overhvelming undertaking if you are not familliar with PP at all. And I would advise you to see if it is possible to slice it into smaller chuncks and try it out one small bit a a time.
I'm not sure where to actually post this (I'm pretty sure someone will chastize me tell me where after of course voting me down - expected).
I've been developing a bunch of files for Safety Training at my facility. The UI is built in Excel with Excel VBA at it's heart to get names and the Training program to run. The Excel file opens A PowerPoint presentation after getting your name and the program you desire and logs that data. When you are done with the presentation it opens as a Word doc - the quiz for that presentation.
My issue is this: currently all of our tests are created in Word (I barely know Word VBA) and would like to continue by just adding some text boxes and check boxes for the answers. I'd like to add some code to facilitate the automatic scoring of these tests by placing a button at the end that "locks" the test (so they can't change answers) then checks and returns the test score.
I don't see where Word Files can be locked as in Excel's "Protect Sheet". The scoring I am using seems to be flawed but that is an issue I can work out later if I stay with Word. I am wondering if it wouldn't be better and maybe easier to do this in Excel as it is set up more for evaluating data input.
Looking for any advice on what others might do if they had a choice to use Word or Excel for creating tests. I currently have no preference (except for the above - which I am not locked into) in which format to use, possibly even using a separate PowerPoint Presentation as the test itself.
To try to answer the question: What you are doing seems like a lot of fun from a VBA perspective, and from a user interface perspective, but it seems to me your intuition is telling you to move the test to excel and I think that is the right thing to do. You have much more ability to lock down the test, could easily score multiple tests and create a multi-test curve, etc, etc.
I need to query a database and save over six million records for later analysis and reports using excel VBA. What would be the best way to do this ? I need to be able to access the data later, analyze it and generate reports on analyzed data ( I should be able to access the whole data locally in my system and should be able to process it fast) How good is MS access to save data if the amount of records run in to millions? I do not have a lot of experience using oracle and VBA together. Is it a good way to go if used with excel VBA? Appreciate it if anyone could give some links which might help me in the task.
Note: I don't have a choice to use another language, due to reasons beyond my control. I am reasonably good in Java, but can't use it.
If you want to manipulate more than 1 million rows of data in Excel, you should look into PowerPivot, which is an add-in for Excel 2010 (it's built into Excel 2013). It allows 100 million rows of data in addition to calculated fields on each row, although these calculations will likely be slower than the SQL backend / Excel frontend solution others have recommended.
I need to query a database and save over six million records for later analysis and reports using excel VBA.
I would hope that the analysis will be done on a SUBSET of those records given that even with Excel 2010 you're limited to 1,048,576 rows.
I need to be able to access the data later, analyze it and generate reports on analyzed data ( I should be able to access the whole data locally in my system and should be able to process it fast) How good is MS access to save data if the amount of records run in to millions?
It'll do it. I've done it (including, many years ago, via a direct connection to an Oracle database), though the joker in the pack is the question of how many columns are in there as one of the comments alluded to. When working with massive data sets it gets pretty easy to start bumping your head on the 2GB file size limit in Access.
"Fast" is another matter. I've largely stopped working with Access because of, amongst other things, what I consider to be unacceptably slow speed when working with large data volumes. Wherever the name "JET" came from[1], it sure as Hades wasn't a metaphor for its speed.
The one advantage that Access does have is that it will allow you to pretty easily (if not quickly) produce Excel-style analysis reports (including some graphical reports) and also allow you to use VBA in the creation of them. SQL Server on the other hand, which is my data cruncher du jour, is much faster but barely has any front end at all. Probably the ideal situation would be (as also alluded to) to use either Access or Excel to do the front end and SQL Server to do the heavy lifting UNLESS (better still) you can do that lifting in Oracle rather than saving the data locally, then just have Excel/VBA create your reports on the summarised queries that you pull directly from Oracle.
I'd shy away from using Excel if the reports run to millions of lines but realistically, no report that runs that long is going to be worthwhile anyway. It's a data dump, not a report.
[1] Yes, yes, I know, Joint Engine Technology.
While implementing a macro via Visual Basic Editor, i got an error "Compile Error: Procedure Too Long".........i wanted to know why is there a limit to the size of the macro and is there any way to increase the allowed size. My macro is pretty big (based on around 150 different cases) and because of this error i will have to divide the task among 8 macros approximately. Is there anyway around it?
Will appreciate your help.
You can speculate on the logic for limiting the text size of a subroutine - maybe they don't think it is necessary to have subs that long - maybe they gain some slight performance boost by doing it - maybe it is just a purposeful limitation to prevent people from recording ridiculously long macros. But in any case it is probably better from a scripting/programming perspective to not have monstrous subs anyways. And with loops you shouldn't need to have subs with that much text in them. So my hypothesis is that they wanted to prevent people from relying on recorded macros when it would be better and more efficient to use loops. But it's just a hypothesis. Good Luck.
Even with the advanced technologies and available database tools (even free alternatives) are available today, it seems that huge number of users are still very comfortable in using Excel IN EVERYTHING! That's why, as a database developer working as one of these users, I am forced to let them use Excel simply because they are very comfortable using it. Especially for the older people who seemed to never gonna let Excel go and embrace a new tool.
Currently, to make their experience as smooth as possible and at the same time, automated, I'm using a lot of database queries inside Excel be it view,SQL or stored procedures. Mostly on ad-hoc (but then became permanent) reports. My question is are there any hopes to improve this situation? I'm sure a lot of organizations are using this same method. Is it possible to completely replace this arrangement with something more logical and efficient both in data collection and reliability? I'm thinking about using Sharepoint. Am I on the right track?
I have also struggled with this problem in the past and can say that what worked for me was a two pronged approach.
Step 1 – Make a good alternative
It sounds like you have already done this, depending on the system there will always be some random report that someone needs to run to suit their “Business Need”. There is no way that you could cram all of these into your system as it would fill up with reports and the users would become snow blind.
Step 2 – User education
Show them the new way of making their own reports (Business objects SSRS whatever) and make sure they are comfortable with it. This is the hardest part as some people like their comfort blanket of excel and wont want to leave it. Give them some templates and some standard reports, maybe even pair develop one or two reports at their desk with them so they get the knack of it.
I will leave on a bit of a daily WTF, there was once this expert business manager who was an expert in business objects. She made reports left right and centre but she treated it like a giant version of excel and her work was littered with examples of this i.e. one report she wrote was to get the dealing totals for a year. No problem I hear you cry just do
SELECT SUM(DealAmount) where DealDate Between X and Y
Nope not our business expert, in here excel frame of mind this was too much like black magic so what she did was return a row for EVERY SINGLE DEAL done in that year and then aggregated it client side to give her a total. In I step and wow the users by reducing this 104mb report that took 17 minutes to run down to a 100kb report that ran in about 15 seconds.
I would go the other way around. And I mean by that, not making queries and database connections within Excel, but using some sort of Web Application to let users (through wizards) generate data they need, and export them to Excel to work.
That way you will have the following benefits:
No DB connections (and probably passwords) in your Excel files
No distribution problem of Excel files with new queries, views, etc.
Centralized approach to data retrieval
Excel for users used to it
Back in the day, I loved using Crystal Reports for ad-hoc reporting. I'm not sure about it's current status, as it seems that SAP has purchased the product: http://www.sap.com/solutions/sapbusinessobjects/sap-crystal-solutions/index.epx