Why excel? Well excel is what is used to import the player salaries.
Now I need the spreadsheet to do the following.
Create teams within salary cap.
Include/exclude specific player function
Build multiple lineups from a selected list of players within the cap
Can I do all of this with excel? or do I need to know excel vba as well?
Also which parts of excel or if necessary excel vba must I need to know to code such a thing? Also if someone could give me a short summary of the steps needed to hypothetically make such a thing it would be great. Thanks.
I'm posting this as a reply because it is too long for a comment window.
Just because Excel has a grid doesn't mean that it is fit for data storage and data handling, on the contrary.
What you typically want to do is create a transparent structure that guarantees the integrity of your data and that allows dynamic portability when needed one day.
Excel is meant to be a spreadsheet, people forget this all the time or they just avoid the topic: although Excel has a grid, doesn't mean that it is a good fit for reliable data storage. It is not even the least complex way of storing data, depending on the amount of VBA that you need to manage all these data and the gates that you unnecessarily open towards potential bugs.
This is why an RDBMS is what will fit your needs, in this case Access would be a good option as it preserves your data integrity if you get the table structure right and it executes a lot of tasks for you that you should otherwise need to program yourself to protect the integrity of your data.
Although you can perform SQL on spreadsheets too, note that Excel does NOT cover related tables (what you typically seem to need for building your teams and salary limits), so what many Excel programmers will typically do is to create their own code to make this cross-table data storage thing work.
Don't do this if the alternative is available and much more reliable and future-proof.
At first sight, it seems that you won't even need any VBA; I'm not sure of all the things you want to do, but my first impression is that you can manage everything with SQL syntax and stored queries in MS Access. You can import Excel sheets into Access if you get their format right so that should not be a problem.
Once your data is stored there, rest assured that you have made your life a lot easier.
Related
I am tasked to create a template that will be Filled up by Business Users with Employee Information, then our program will load this into the Database using External Tables.
However, our Business Users constantly change the template by adding, removing or reordering fields.
I am convinced to use XLSX instead of CSV so that I can lock the Column Headers so they cannot remove, add and reorder the columns.
However, When i query the External Table, it shows Non-ASCII Characters when reading XLSX because its in Binary.
How can i do either of the following?
Effectively Read Excel Files from External Tables
Lock the Headers of CSV Files?
What you have here is a political problem, but you are looking for a technical fix. Not a good fit.
The problem comes in two halves:
Somebody decided it was a good idea to collect user input in a spreadsheet, which it is generally not.
Users are fiddling with the input format, which they should not.
Fixes are:
Strictly enforce the data structure. Reject any CSV which doesn't natch and make the users edit them. They will quickly tire of tweaking the spreadsheets when they realise they're just creating more work for themselves. But they will also get resentful, so consider ...
Building a data input screen. It's pretty simple to knock up a spreadsheet-like grid UI. You don't need anything complicated in Java: Oracle's Apex is intended for exactly this sort of thing. Find out more.
However, if you are stuck with Excel as a UI I suggest you have a look at Anton Scheffer's excellent PLSQL as_read_xlsx package on the Amis site. Check it out. You'll probably need to replace your external table with a view over a table (perhaps pipelined) function.
I'm perfectly happy with excel; I know the codes and I find the interface very intuitive. The only problem I have now is that I have lots of formulas in several columns, which are linked to other excel files and am tracking sales over time. Currently I have 1500+ rows of data and sometimes Excel has trouble to calculate all the necessary codes and I need a way to make sure that into the future, when there are 10000+ or more rows, it is possible to run the code without Excel stopping/freezing. My boss says using SQL should help. However, I am unfamiliar with it and know that excel and SQL can be used similarly.
Ultimately, I want to know if I can run the excel code in SQL or if I can calculate small datasets (sets that are pulled periodically) in excel and them export to SQL automatically instead of having to go through the wizard for importing data. Also, I would need to attach the small datasets into the large one. Any ideas other than just learning SQL? This needs to be accessible to many people who don't know SQL so simply learning SQL isn't too helpful.
If you're familiar with Excel and its formulas, it won't be too arduous for you to pick up on SQL. In addition to that, I can copy and paste outputs from SQL Sever into Excel sheets that have a graph auto-built (since I use Express) and it's a simple copy-and-paste into an Excel sheet.
While I don't know all your calculations, I haven't seen Excel be able to do something that SQL couldn't do and when you consider the benefit of indexing among the freedom to organize your data how you want (and have saved stored procedures), a switch might only be temporarily inconvenient while you pick up on SQL, and after that, you'll easily produce what you need.
Ultimately, I want to know if I can run the excel code in SQL
Not always exactly identical, but you can run similar structured code. For instance:
SELECT AVG(Sales) "AverageSales"
FROM Sales
VERSUS
=AVERAGE(A2:A2000)
or
SELECT (((DollarToday - DollarYesterday)/DollarYesterday)*100) AS "DollarDelta"
FROM USD
VERSUS
=(((A2-A1)/A1)*100)
Suppose you have an Excel workbook and you need to write a macro that takes inputs from many different cell references, and updates values at many different cell references, how do you keep the code neat and maintainable?
It would be helpful to know:
best practices
useful tricks
unavoidable difficulties
necessary trade offs
If there are links to existing guides or discussions that would be helpful too. I haven't been able to find any.
Edit: I found http://www.eusprig.org/best-practice.htm very useful - from the European Spreadsheet Risk Interest Group (EuSPRIG).
It slightly depends om what the macro is going to do, but I use 'calculation' sheets, where I gather together the data I need for the macro, and output the results there.
I tend to do this do in defined ranges.
The result data can then be referenced from elsewhere.
Tricks: One thing I do is to create a visual 'check off' for each piece of input data as it's used. This just enables me to make sure that all the data I thought I was going to use, I have used.
Following Naming criteria is better solution , irrespictve of language.
in_name_range, out_name_range
in_num_range, out_num_range
Check points and adding watch , would surely help.
If you are going for modularity, Take care about updated ranges
(As you can't return more than one value at a time better write ranges in some predefined order in some sheet. This works for me.)
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.
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