For the scope of what you are attempting to do you should migrate the whole app to an online Database
- the online DB can generate a tailored .xls (based on parameters entered or set in the web interface) for your mail merge or Word
file links if still required
- or better still your final reports can be generated in web interface ready for print/saving w/o need for Word
While Excel is quite powerful it is
1) not secure (password protection is easily broken)
2) a single user product
3) w/o extensive VBA has limited validation & cross checking
FYI
I too have created several of those Excel apps w/ 100's of linked workbooks then tied to MS Word mail merges or wks links (resultant
files over 300 MB)
- but over time I found they all need to be upgraded to a DB and are much easier to maintain now
For intranet use even an Access Front End / Back End DB will outperform Excel in a project of that scope
--
_____________________________________________
SBR @ ENJOY (-: [ Microsoft MVP - FrontPage ]
"Warning - Using the F1 Key will not break anything!" (-;
To find the best Newsgroup for FrontPage support see:
http://www.frontpagemvps.com/FrontPageNewsGroups/tabid/53/Default.aspx
_____________________________________________
| Boy, don't you love it when you ask a question and the answer is, "prepare
| yourself for the Cracks of Doom?" Thanks Kevin for the straight skinny and
| some damn good questions.
|
| Here's the answer to those questions...
|
| 1. As things currently stand, we run the report scenario (financial
| analysis) in EXCEL then open the WORD document that contains links to the
| EXCEL spreadsheets (there are about 500 of them - no kidding) and updates the
| pictures of the spreadsheets in the WORD document. The WORD document
| presents an integrated final report that is pretty slick to look at but a bit
| problematic to work with as it constantly chokes my computer.
|
| 2. The security of the data means the proprietary calculations and database
| elements that make up the spreadsheet. We want these to stay on the server
| and not be transferred to people - lest our competitors have a field day once
| they get their hands on this reporting tool. So, we want the results to be
| transferred to the user and not the "how-to" or "why".
|
| 3. The input data constitutes the variables the user wants to have be part
| of the unique transaction analysis. The current EXCEL design allows for
| approximately 700 variables. Most people won't want any part of fooling with
| over 700 variables, but we want to pre-program some goodies so they don't
| have to fool with them anyway, but retain the option that they can change
| variables if they would like to for the sake of sensitivity testing (as one
| example).
|
| 4. The goal of the process is for the user to be able to get an incredibly
| detailed report generated that has real value and meaning for the user that
| cannot otherwise be obtained in a reasonable time period and for a reasonable
| cost.
|
| I hope this lays it out a bit better....
|
| "Kevin Spencer" wrote:
|
| > Hi Clint,
| >
| > You've got a heck of a problem there. This is the sort of job that many
| > professional developers would have trouble doing.
| >
| > But, if you really want to tackle it, I hope you have at least 6 months
| > free. Here's your starting point: You need to exactly define your
| > requirements. Instead of "they input the data" you have to define what
| > exactly this process represents. You have stated that "the original
| > spreadsheet structure must stay secure." What do you mean by "secure?" If
| > you mean that nobody can change it, don't worry: A browser downloads
| > *copies* of files, not the actual files. But how exactly is this excel
| > workbook "connected to" a WORD file. What is the functionality there? Keep
| > in mind that nobody is touching any of the actual files on the server. This
| > presents all sorts of problems for you, as the copy on the client isn't
| > going to be connected to anything. So, you need to figure out what the
| > significance of this "connection" is. What does the Word file do? Why? What
| > is the exact goal of the process which the user is participating in?
| >
| > In order to take on such a job, you must first know exactly what each
| > component in the current offline process does. Then you must know enough
| > about HTTP, web application technology, Excel, Word, and whatever other
| > programming tools may come into play to evaluate how to *change* the process
| > for a client-server, HTTP, web-based application. And you *will* have to
| > change it. There is no memory passing back and forth between client browser
| > and web server. Only files.
| >
| > --
| > HTH,
| >
| > Kevin Spencer
| > Microsoft MVP
| > Professional Numbskull
| >
| > Show me your certification without works,
| > and I'll show my certification
| > *by* my works.
| >
| > | > > I'm using FP2000 and Office 2003. I want to put an Excel workbook online
| > > to
| > > generate spreadsheets for users. They input the data thru a webpage based
| > > GUI "thingy" and the output is presented in a file or via email. The
| > > original spreadsheet structure must stay secure (lest someone accidentally
| > > dismember the beast). The workbook is a real beast - about 18 megs and is
| > > normally connected to a WORD file that is about 75 megs (that's right - 75
| > > megs). I'd like to be able to get this up for our clients to use on an
| > > interactive basis but have no clue - none at all - about where to start
| > > with
| > > this project.
| > >
| > > I know enough HTML to be considered armed and dangerous with FP2000, but
| > > can
| > > get it on when I need to do the job in front of me.
| > >
| > > Where do I start with this one? Any suggestions?
| >
| >
| >
