Hi,

I've developped an application in VB6 that uses the Excel API (Microsoft
Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many users) of my
company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls files,
that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning the
redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

Jérémie

Here's a start:

http://support.microsoft.com/kb/163410

--JP

On Mar 9, 11:04*am, "J r mie Gent" wrote:
Hi,

I've developped an application in VB6 that uses the Excel API (Microsoft
Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many users) of my
company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls files,
that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning the
redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

J r mie

Thanks for your answer JP!

however, this is not quite what I want, cf following Note in this Article:
"NOTE: Using the methods described in this article, your users will only be
able to view your Microsoft Excel spreadsheets, Word documents, or
PowerPoint presentations. They will not be able to make any modifications to
the files"

I don't actually need my users to view the XLS Files, but I definitely need
my application to read them and write into them.

I was also thinking of accessing the xls files via ODBC, which I guess
wouldn't need any license. I wouldn't be able to change the format of the
cells though (font etc.). And If I'm not mistaken, the ODBC Microsoft Excel
Driver is in ODBCJT32.DLL which is included in standard XP Pro installation,
is that correct?

Thanks for your help!
However again for me, the best way would be to have a legal way to use the
'Microsoft Excel 9.0 Object Library' on PC without Excel license.


"JP" schrieb im Newsbeitrag
...
Here's a start:

http://support.microsoft.com/kb/163410

--JP

On Mar 9, 11:04 am, "J r mie Gent" wrote:
Hi,

I've developped an application in VB6 that uses the Excel API (Microsoft
Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many users) of my
company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls files,
that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning the
redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

J r mie

Your users will need a license and key to have Excel installed on their
systems. Not sure how you would obtain Excel 9 (2000) though, other than
with an MSDN subscription.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Hi,

I've developped an application in VB6 that uses the Excel API (Microsoft
Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many users) of my
company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls files,
that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning the
redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

Jérémie

Thanks Peter,

but I don't want my users to have Excel on their computers. They don't need
that.
They just need my application, but this application (written in VB6) uses
the Excel API.
Basically, my application refers to the Microsoft Excel 9.0 Object Library.
I then use the Excel Application Object declared with this statement:
Dim xlApp As New Excel.Application

Thanks for your help!
Jérémie

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Your users will need a license and key to have Excel installed on their
systems. Not sure how you would obtain Excel 9 (2000) though, other than
with an MSDN subscription.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Hi,

I've developped an application in VB6 that uses the Excel API (Microsoft
Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many users) of
my company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls
files, that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning the
redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

Jérémie

Dim xlApp As New Excel.Application

That's Excel, still need a licence even if you only want to automate it,
sorry!

There might be other approaches depending on what you are doing and the
overall objectives.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Thanks Peter,

but I don't want my users to have Excel on their computers. They don't
need that.
They just need my application, but this application (written in VB6) uses
the Excel API.
Basically, my application refers to the Microsoft Excel 9.0 Object
Library.
I then use the Excel Application Object declared with this statement:
Dim xlApp As New Excel.Application

Thanks for your help!
Jérémie

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Your users will need a license and key to have Excel installed on their
systems. Not sure how you would obtain Excel 9 (2000) though, other than
with an MSDN subscription.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Hi,

I've developped an application in VB6 that uses the Excel API (Microsoft
Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many users) of
my company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls
files, that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning the
redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

Jérémie

Ok thanks Peter, that's what I was afraid of.

I considered the ODBC approach, which would then be free I think. With that,
I can access and modify the data in the Excel sheets, but not the format of
the cells or other meta data included in the excel files.

I'll see, but I'm afraid I'll have to buy Excel licenses for all my users
finally. Unless you've got other ideas?
Thank you anyway!

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Dim xlApp As New Excel.Application

That's Excel, still need a licence even if you only want to automate it,
sorry!

There might be other approaches depending on what you are doing and the
overall objectives.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Thanks Peter,

but I don't want my users to have Excel on their computers. They don't
need that.
They just need my application, but this application (written in VB6) uses
the Excel API.
Basically, my application refers to the Microsoft Excel 9.0 Object
Library.
I then use the Excel Application Object declared with this statement:
Dim xlApp As New Excel.Application

Thanks for your help!
Jérémie

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Your users will need a license and key to have Excel installed on their
systems. Not sure how you would obtain Excel 9 (2000) though, other than
with an MSDN subscription.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Hi,

I've developped an application in VB6 that uses the Excel API
(Microsoft Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many users) of
my company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls
files, that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning the
redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

Jérémie

Other ways, if any, really depend on what you are doing. I don't quite
follow why you need to write to Excel files on users system if, as you
imply, the user will not need to view the files on his system. If the
objective is to create files on user1's system to be sent to user2 I would
have thought the file could be compiled elsewhere based on the supplied
data.

I don't think the ODBC approach would work, but I could be wrong.

Excel file formats are now effectively "open source", IOW the binary formats
are fully documented, and freely available for anyone to make their own apps
to read/write Excel files. For 2003 and earlier you might look into BIFF (or
BIFF8) editors. There is quite a lot of free source code which you can
integrate into your own app, but a (very) steep learning curve. There are
also commercially available app's and dlls which should make things
considerably easier, though I have not looked into any of these.

Excel 2007 files are entirely XML, ie a zipped series of XML files. Not sure
if there are any commercial tools for read/write these.

The bottom line is you do not need Excel to read or write Excel files.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Ok thanks Peter, that's what I was afraid of.

I considered the ODBC approach, which would then be free I think. With
that, I can access and modify the data in the Excel sheets, but not the
format of the cells or other meta data included in the excel files.

I'll see, but I'm afraid I'll have to buy Excel licenses for all my users
finally. Unless you've got other ideas?
Thank you anyway!

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Dim xlApp As New Excel.Application

That's Excel, still need a licence even if you only want to automate it,
sorry!

There might be other approaches depending on what you are doing and the
overall objectives.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Thanks Peter,

but I don't want my users to have Excel on their computers. They don't
need that.
They just need my application, but this application (written in VB6)
uses the Excel API.
Basically, my application refers to the Microsoft Excel 9.0 Object
Library.
I then use the Excel Application Object declared with this statement:
Dim xlApp As New Excel.Application

Thanks for your help!
Jérémie

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Your users will need a license and key to have Excel installed on their
systems. Not sure how you would obtain Excel 9 (2000) though, other
than with an MSDN subscription.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Hi,

I've developped an application in VB6 that uses the Excel API
(Microsoft Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many users)
of my company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls
files, that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning the
redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

Jérémie

Thanks again for your answer Peter.

for a better understanding of what I'm doing, here's a "short" description
(basically it's a small CRM):
I work in a german subsidiary of a french company. We've got several
networks of salesmen here in germany and our own local ERP (based on SQL
Server).
Every night, some processes that I programmed (in VB6) connect to the ERP,
extract sales data and create an XLS File for each Salesman (with the Excel
9.0 Object Library). Those XLS Files are then placed on an FTP, and the user
can update his data daily thanks to a small VB6 application I made. Those
files contain all the customers of the salesman's region and all detailed
orders of the last 12 months. A pivot table shows the data and provides an
easy way for the user to get to the info quickly (what product was sold when
to whom).
On the top of that, those XLS files contain a whole bunch of VBA code,
transforming the XLS file into a small dynamic application that not only
provides sales info (+other) to the user but also allows him to write new
orders for his customers (with product info such as price, availability,
current discounts ...) . The orders are then sent automatically to the
subsidiary, where we have another tool that I made that extracts the data,
checks it and writes the orders into the ERP.

My problem is the following: Some of my users (Salesmen) had office 2000,
others Office 2003 OEM. They will all get new laptops and we made a request
to get new office licenses, which wasn't really approved. Instead, open
office was proposed to us. I looked into it and it seems to me that I would
have too much to adapt to reprogramm everything for openoffice macros.
Especially on the server part that creates the files (with automation), but
also on the user side. Plus I wasn't really thrilled with the pivot tables
in open office. That's why I thought I'd keep Excel licenses internally (on
the server and in our sales dept. where they import the orders with my tool)
and would program an independant VB6 application accessing the XLS Files on
the customer side. My main objective is that the data flow doesn't change
(xls files), to minimize the changes in the programmation (server and sales
dept. tools would remain the same).
But if I need an Excel license to use automation on the user side, I might
as well buy Excel for all my users (even though that makes big costs) and
leave my CRM in Excel (2010 for everybody - as soon as it's available - so
some adaptation in the macros might be needed).

Now to your suggestions: I don't really want to make a huge application for
my users (i.e. parse xls files with additionnal code, which by the way is to
my opinion easier with ODBC and SQL when it goes only of reading the cells
values). Before all, I don't want the next version of the application to be
worse (or less user-friendly) than the previous one, and I suppose the code
wouldn't provide any Pivot Table functionnality ... ?
Anyway, if I had time to make such changes, I might better rethink the whole
process and redefine the data flow (for example text instead of xls and only
data, not the application itself). The advantage of recreating the whole
user application every night is that if I add a function to the app today,
all my users have the last version tomorrow.

So as a conclusion, I'll try to put pressure so that we can buy Excel
licenses for our salesmen (and sales dept. + server). I'll just have to hope
that it'll be granted (it's a lot of money).
If it's not accepted ... then I'll have a lot of work!!!! I would then have
a deeper look at what you suggested (free code to parse xls files - Version
2000)

Thanks again!


"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Other ways, if any, really depend on what you are doing. I don't quite
follow why you need to write to Excel files on users system if, as you
imply, the user will not need to view the files on his system. If the
objective is to create files on user1's system to be sent to user2 I would
have thought the file could be compiled elsewhere based on the supplied
data.

I don't think the ODBC approach would work, but I could be wrong.

Excel file formats are now effectively "open source", IOW the binary
formats are fully documented, and freely available for anyone to make
their own apps to read/write Excel files. For 2003 and earlier you might
look into BIFF (or BIFF8) editors. There is quite a lot of free source
code which you can integrate into your own app, but a (very) steep
learning curve. There are also commercially available app's and dlls which
should make things considerably easier, though I have not looked into any
of these.

Excel 2007 files are entirely XML, ie a zipped series of XML files. Not
sure if there are any commercial tools for read/write these.

The bottom line is you do not need Excel to read or write Excel files.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Ok thanks Peter, that's what I was afraid of.

I considered the ODBC approach, which would then be free I think. With
that, I can access and modify the data in the Excel sheets, but not the
format of the cells or other meta data included in the excel files.

I'll see, but I'm afraid I'll have to buy Excel licenses for all my users
finally. Unless you've got other ideas?
Thank you anyway!

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Dim xlApp As New Excel.Application

That's Excel, still need a licence even if you only want to automate it,
sorry!

There might be other approaches depending on what you are doing and the
overall objectives.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Thanks Peter,

but I don't want my users to have Excel on their computers. They don't
need that.
They just need my application, but this application (written in VB6)
uses the Excel API.
Basically, my application refers to the Microsoft Excel 9.0 Object
Library.
I then use the Excel Application Object declared with this statement:
Dim xlApp As New Excel.Application

Thanks for your help!
Jérémie

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Your users will need a license and key to have Excel installed on
their systems. Not sure how you would obtain Excel 9 (2000) though,
other than with an MSDN subscription.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Hi,

I've developped an application in VB6 that uses the Excel API
(Microsoft Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many users)
of my company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls
files, that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning the
redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

Jérémie

Just a few comments

Some of my users (Salesmen) had office 2000, others Office 2003 OEM. They
will all get new laptops

Not sure I totally follow. Why do you particularly want 2000 licences if, as
you say, your all your 2000 users are getting new laptops. Why not 2003 or
2007.

I don't really want to make a huge application for my users (i.e. parse
xls files with additionnal code, which by the way is to my opinion easier
with ODBC and SQL when it goes only of reading the cells values).

ODBC and SQL may allow you to read and write data but not, AFAIK, do
anything else (eg create, format, pivot tables etc)

free code to parse xls files - Version 2000

The way BIFF utilities tend to work is supply a class/method structure
exposed for your needs, eg read/write not only data but all other aspects of
an Excel file, including created from scratch. In effect you simply input
what you want to extract or change. From v8 they are not version specific,
at least not in the sense I think you mean.

There is plenty of VB source code out there that you can compile into your
VB6 app (don't recall seeing anything that caters for pivot tables). The
commercial utilities tend to be in C, either exposing a UI or functions you
can call with your VB6.

It sounds though you'd much prefer your users are equipped with Excel, and
there may well be other good reasons they should be beyond your own concerns
(staff *like* to have such things!). I don't know the costs but if only
Excel is required I wouldn't have thought a multi-user licence for 2007 (and
soon 2010) would be work out so expensive per user (maybe less than OEM).

I'm still confused why you want 2000 if no users will have 2000 on their
machines. It might be worth checking your 2000 license, it might allow you
to deactivate and fully uninstall from your old machine(s) and reinstall in
the new. Definitely would not be able to do that if the original license was
OEM, otherwise not sure. Even if you can, Office 2000 is not officially
supported on Vista but that's not a licensing issue, but Excel 2000 works
fine in Vista (probably OK in W7 but I don't know for sure).

Regards,
Peter T



Regards,
Peter T


"Jérémie Gent" wrote in message
...
Thanks again for your answer Peter.

for a better understanding of what I'm doing, here's a "short" description
(basically it's a small CRM):
I work in a german subsidiary of a french company. We've got several
networks of salesmen here in germany and our own local ERP (based on SQL
Server).
Every night, some processes that I programmed (in VB6) connect to the ERP,
extract sales data and create an XLS File for each Salesman (with the
Excel 9.0 Object Library). Those XLS Files are then placed on an FTP, and
the user can update his data daily thanks to a small VB6 application I
made. Those files contain all the customers of the salesman's region and
all detailed orders of the last 12 months. A pivot table shows the data
and provides an easy way for the user to get to the info quickly (what
product was sold when to whom).
On the top of that, those XLS files contain a whole bunch of VBA code,
transforming the XLS file into a small dynamic application that not only
provides sales info (+other) to the user but also allows him to write new
orders for his customers (with product info such as price, availability,
current discounts ...) . The orders are then sent automatically to the
subsidiary, where we have another tool that I made that extracts the data,
checks it and writes the orders into the ERP.

My problem is the following: Some of my users (Salesmen) had office 2000,
others Office 2003 OEM. They will all get new laptops and we made a
request to get new office licenses, which wasn't really approved. Instead,
open office was proposed to us. I looked into it and it seems to me that I
would have too much to adapt to reprogramm everything for openoffice
macros. Especially on the server part that creates the files (with
automation), but also on the user side. Plus I wasn't really thrilled with
the pivot tables in open office. That's why I thought I'd keep Excel
licenses internally (on the server and in our sales dept. where they
import the orders with my tool) and would program an independant VB6
application accessing the XLS Files on the customer side. My main
objective is that the data flow doesn't change (xls files), to minimize
the changes in the programmation (server and sales dept. tools would
remain the same).
But if I need an Excel license to use automation on the user side, I might
as well buy Excel for all my users (even though that makes big costs) and
leave my CRM in Excel (2010 for everybody - as soon as it's available - so
some adaptation in the macros might be needed).

Now to your suggestions: I don't really want to make a huge application
for my users (i.e. parse xls files with additionnal code, which by the way
is to my opinion easier with ODBC and SQL when it goes only of reading the
cells values). Before all, I don't want the next version of the
application to be worse (or less user-friendly) than the previous one, and
I suppose the code wouldn't provide any Pivot Table functionnality ... ?
Anyway, if I had time to make such changes, I might better rethink the
whole process and redefine the data flow (for example text instead of xls
and only data, not the application itself). The advantage of recreating
the whole user application every night is that if I add a function to the
app today, all my users have the last version tomorrow.

So as a conclusion, I'll try to put pressure so that we can buy Excel
licenses for our salesmen (and sales dept. + server). I'll just have to
hope that it'll be granted (it's a lot of money).
If it's not accepted ... then I'll have a lot of work!!!! I would then
have a deeper look at what you suggested (free code to parse xls files -
Version 2000)

Thanks again!


"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Other ways, if any, really depend on what you are doing. I don't quite
follow why you need to write to Excel files on users system if, as you
imply, the user will not need to view the files on his system. If the
objective is to create files on user1's system to be sent to user2 I
would have thought the file could be compiled elsewhere based on the
supplied data.

I don't think the ODBC approach would work, but I could be wrong.

Excel file formats are now effectively "open source", IOW the binary
formats are fully documented, and freely available for anyone to make
their own apps to read/write Excel files. For 2003 and earlier you might
look into BIFF (or BIFF8) editors. There is quite a lot of free source
code which you can integrate into your own app, but a (very) steep
learning curve. There are also commercially available app's and dlls
which should make things considerably easier, though I have not looked
into any of these.

Excel 2007 files are entirely XML, ie a zipped series of XML files. Not
sure if there are any commercial tools for read/write these.

The bottom line is you do not need Excel to read or write Excel files.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Ok thanks Peter, that's what I was afraid of.

I considered the ODBC approach, which would then be free I think. With
that, I can access and modify the data in the Excel sheets, but not the
format of the cells or other meta data included in the excel files.

I'll see, but I'm afraid I'll have to buy Excel licenses for all my
users finally. Unless you've got other ideas?
Thank you anyway!

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Dim xlApp As New Excel.Application

That's Excel, still need a licence even if you only want to automate
it, sorry!

There might be other approaches depending on what you are doing and the
overall objectives.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Thanks Peter,

but I don't want my users to have Excel on their computers. They don't
need that.
They just need my application, but this application (written in VB6)
uses the Excel API.
Basically, my application refers to the Microsoft Excel 9.0 Object
Library.
I then use the Excel Application Object declared with this statement:
Dim xlApp As New Excel.Application

Thanks for your help!
Jérémie

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Your users will need a license and key to have Excel installed on
their systems. Not sure how you would obtain Excel 9 (2000) though,
other than with an MSDN subscription.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Hi,

I've developped an application in VB6 that uses the Excel API
(Microsoft Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many users)
of my company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls
files, that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning the
redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

Jérémie

I don't want to buy 2000 licenses, I'll certainly buy 2010 when it's out -
but only if I have to buy something meaning if it's accepted.
You're right, the staff will need office apps, but if the costs aren't
approved, then they'll have openoffice (free).
AFAIK, costs per user for only Excel 2007 are above 200 eur (Volume license,
lower than 500 users), which for a lot of users still makes a big
investment.

Finally, you're right, we've got a lot of Office 2000 licenses that are not
OEM, so we could use them (as we own them anyway) to install only Excel, and
other office solutions would come from openoffice. Thanks for the idea, I
should have thought of that myself!

And if none of this is accepted, then I'll dive into the BIFF classes you
mention.

Thanks a lot for all those good advice!

Jérémie


"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Just a few comments

Some of my users (Salesmen) had office 2000, others Office 2003 OEM. They
will all get new laptops

Not sure I totally follow. Why do you particularly want 2000 licences if,
as you say, your all your 2000 users are getting new laptops. Why not 2003
or 2007.

I don't really want to make a huge application for my users (i.e. parse
xls files with additionnal code, which by the way is to my opinion easier
with ODBC and SQL when it goes only of reading the cells values).

ODBC and SQL may allow you to read and write data but not, AFAIK, do
anything else (eg create, format, pivot tables etc)

free code to parse xls files - Version 2000

The way BIFF utilities tend to work is supply a class/method structure
exposed for your needs, eg read/write not only data but all other aspects
of an Excel file, including created from scratch. In effect you simply
input what you want to extract or change. From v8 they are not version
specific, at least not in the sense I think you mean.

There is plenty of VB source code out there that you can compile into your
VB6 app (don't recall seeing anything that caters for pivot tables). The
commercial utilities tend to be in C, either exposing a UI or functions
you can call with your VB6.

It sounds though you'd much prefer your users are equipped with Excel, and
there may well be other good reasons they should be beyond your own
concerns (staff *like* to have such things!). I don't know the costs but
if only Excel is required I wouldn't have thought a multi-user licence for
2007 (and soon 2010) would be work out so expensive per user (maybe less
than OEM).

I'm still confused why you want 2000 if no users will have 2000 on their
machines. It might be worth checking your 2000 license, it might allow you
to deactivate and fully uninstall from your old machine(s) and reinstall
in the new. Definitely would not be able to do that if the original
license was OEM, otherwise not sure. Even if you can, Office 2000 is not
officially supported on Vista but that's not a licensing issue, but Excel
2000 works fine in Vista (probably OK in W7 but I don't know for sure).

Regards,
Peter T



Regards,
Peter T


"Jérémie Gent" wrote in message
...
Thanks again for your answer Peter.

for a better understanding of what I'm doing, here's a "short"
description (basically it's a small CRM):
I work in a german subsidiary of a french company. We've got several
networks of salesmen here in germany and our own local ERP (based on SQL
Server).
Every night, some processes that I programmed (in VB6) connect to the
ERP, extract sales data and create an XLS File for each Salesman (with
the Excel 9.0 Object Library). Those XLS Files are then placed on an FTP,
and the user can update his data daily thanks to a small VB6 application
I made. Those files contain all the customers of the salesman's region
and all detailed orders of the last 12 months. A pivot table shows the
data and provides an easy way for the user to get to the info quickly
(what product was sold when to whom).
On the top of that, those XLS files contain a whole bunch of VBA code,
transforming the XLS file into a small dynamic application that not only
provides sales info (+other) to the user but also allows him to write new
orders for his customers (with product info such as price, availability,
current discounts ...) . The orders are then sent automatically to the
subsidiary, where we have another tool that I made that extracts the
data, checks it and writes the orders into the ERP.

My problem is the following: Some of my users (Salesmen) had office 2000,
others Office 2003 OEM. They will all get new laptops and we made a
request to get new office licenses, which wasn't really approved.
Instead, open office was proposed to us. I looked into it and it seems to
me that I would have too much to adapt to reprogramm everything for
openoffice macros. Especially on the server part that creates the files
(with automation), but also on the user side. Plus I wasn't really
thrilled with the pivot tables in open office. That's why I thought I'd
keep Excel licenses internally (on the server and in our sales dept.
where they import the orders with my tool) and would program an
independant VB6 application accessing the XLS Files on the customer side.
My main objective is that the data flow doesn't change (xls files), to
minimize the changes in the programmation (server and sales dept. tools
would remain the same).
But if I need an Excel license to use automation on the user side, I
might as well buy Excel for all my users (even though that makes big
costs) and leave my CRM in Excel (2010 for everybody - as soon as it's
available - so some adaptation in the macros might be needed).

Now to your suggestions: I don't really want to make a huge application
for my users (i.e. parse xls files with additionnal code, which by the
way is to my opinion easier with ODBC and SQL when it goes only of
reading the cells values). Before all, I don't want the next version of
the application to be worse (or less user-friendly) than the previous
one, and I suppose the code wouldn't provide any Pivot Table
functionnality ... ?
Anyway, if I had time to make such changes, I might better rethink the
whole process and redefine the data flow (for example text instead of xls
and only data, not the application itself). The advantage of recreating
the whole user application every night is that if I add a function to the
app today, all my users have the last version tomorrow.

So as a conclusion, I'll try to put pressure so that we can buy Excel
licenses for our salesmen (and sales dept. + server). I'll just have to
hope that it'll be granted (it's a lot of money).
If it's not accepted ... then I'll have a lot of work!!!! I would then
have a deeper look at what you suggested (free code to parse xls files -
Version 2000)

Thanks again!


"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Other ways, if any, really depend on what you are doing. I don't quite
follow why you need to write to Excel files on users system if, as you
imply, the user will not need to view the files on his system. If the
objective is to create files on user1's system to be sent to user2 I
would have thought the file could be compiled elsewhere based on the
supplied data.

I don't think the ODBC approach would work, but I could be wrong.

Excel file formats are now effectively "open source", IOW the binary
formats are fully documented, and freely available for anyone to make
their own apps to read/write Excel files. For 2003 and earlier you might
look into BIFF (or BIFF8) editors. There is quite a lot of free source
code which you can integrate into your own app, but a (very) steep
learning curve. There are also commercially available app's and dlls
which should make things considerably easier, though I have not looked
into any of these.

Excel 2007 files are entirely XML, ie a zipped series of XML files. Not
sure if there are any commercial tools for read/write these.

The bottom line is you do not need Excel to read or write Excel files.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Ok thanks Peter, that's what I was afraid of.

I considered the ODBC approach, which would then be free I think. With
that, I can access and modify the data in the Excel sheets, but not the
format of the cells or other meta data included in the excel files.

I'll see, but I'm afraid I'll have to buy Excel licenses for all my
users finally. Unless you've got other ideas?
Thank you anyway!

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Dim xlApp As New Excel.Application

That's Excel, still need a licence even if you only want to automate
it, sorry!

There might be other approaches depending on what you are doing and
the overall objectives.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Thanks Peter,

but I don't want my users to have Excel on their computers. They
don't need that.
They just need my application, but this application (written in VB6)
uses the Excel API.
Basically, my application refers to the Microsoft Excel 9.0 Object
Library.
I then use the Excel Application Object declared with this statement:
Dim xlApp As New Excel.Application

Thanks for your help!
Jérémie

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Your users will need a license and key to have Excel installed on
their systems. Not sure how you would obtain Excel 9 (2000) though,
other than with an MSDN subscription.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Hi,

I've developped an application in VB6 that uses the Excel API
(Microsoft Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many
users) of my company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in .xls
files, that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning
the redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

Jérémie

Think I mentioned XML before but something you might look into is
"SpreadsheetML"

Regards,
Peter T

"Jérémie Gent" wrote in message
...
I don't want to buy 2000 licenses, I'll certainly buy 2010 when it's out -
but only if I have to buy something meaning if it's accepted.
You're right, the staff will need office apps, but if the costs aren't
approved, then they'll have openoffice (free).
AFAIK, costs per user for only Excel 2007 are above 200 eur (Volume
license, lower than 500 users), which for a lot of users still makes a big
investment.

Finally, you're right, we've got a lot of Office 2000 licenses that are
not OEM, so we could use them (as we own them anyway) to install only
Excel, and other office solutions would come from openoffice. Thanks for
the idea, I should have thought of that myself!

And if none of this is accepted, then I'll dive into the BIFF classes you
mention.

Thanks a lot for all those good advice!

Jérémie


"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Just a few comments

Some of my users (Salesmen) had office 2000, others Office 2003 OEM.
They will all get new laptops

Not sure I totally follow. Why do you particularly want 2000 licences if,
as you say, your all your 2000 users are getting new laptops. Why not
2003 or 2007.

I don't really want to make a huge application for my users (i.e. parse
xls files with additionnal code, which by the way is to my opinion
easier with ODBC and SQL when it goes only of reading the cells values).

ODBC and SQL may allow you to read and write data but not, AFAIK, do
anything else (eg create, format, pivot tables etc)

free code to parse xls files - Version 2000

The way BIFF utilities tend to work is supply a class/method structure
exposed for your needs, eg read/write not only data but all other aspects
of an Excel file, including created from scratch. In effect you simply
input what you want to extract or change. From v8 they are not version
specific, at least not in the sense I think you mean.

There is plenty of VB source code out there that you can compile into
your VB6 app (don't recall seeing anything that caters for pivot tables).
The commercial utilities tend to be in C, either exposing a UI or
functions you can call with your VB6.

It sounds though you'd much prefer your users are equipped with Excel,
and there may well be other good reasons they should be beyond your own
concerns (staff *like* to have such things!). I don't know the costs but
if only Excel is required I wouldn't have thought a multi-user licence
for 2007 (and soon 2010) would be work out so expensive per user (maybe
less than OEM).

I'm still confused why you want 2000 if no users will have 2000 on their
machines. It might be worth checking your 2000 license, it might allow
you to deactivate and fully uninstall from your old machine(s) and
reinstall in the new. Definitely would not be able to do that if the
original license was OEM, otherwise not sure. Even if you can, Office
2000 is not officially supported on Vista but that's not a licensing
issue, but Excel 2000 works fine in Vista (probably OK in W7 but I don't
know for sure).

Regards,
Peter T



Regards,
Peter T


"Jérémie Gent" wrote in message
...
Thanks again for your answer Peter.

for a better understanding of what I'm doing, here's a "short"
description (basically it's a small CRM):
I work in a german subsidiary of a french company. We've got several
networks of salesmen here in germany and our own local ERP (based on SQL
Server).
Every night, some processes that I programmed (in VB6) connect to the
ERP, extract sales data and create an XLS File for each Salesman (with
the Excel 9.0 Object Library). Those XLS Files are then placed on an
FTP, and the user can update his data daily thanks to a small VB6
application I made. Those files contain all the customers of the
salesman's region and all detailed orders of the last 12 months. A pivot
table shows the data and provides an easy way for the user to get to the
info quickly (what product was sold when to whom).
On the top of that, those XLS files contain a whole bunch of VBA code,
transforming the XLS file into a small dynamic application that not only
provides sales info (+other) to the user but also allows him to write
new orders for his customers (with product info such as price,
availability, current discounts ...) . The orders are then sent
automatically to the subsidiary, where we have another tool that I made
that extracts the data, checks it and writes the orders into the ERP.

My problem is the following: Some of my users (Salesmen) had office
2000, others Office 2003 OEM. They will all get new laptops and we made
a request to get new office licenses, which wasn't really approved.
Instead, open office was proposed to us. I looked into it and it seems
to me that I would have too much to adapt to reprogramm everything for
openoffice macros. Especially on the server part that creates the files
(with automation), but also on the user side. Plus I wasn't really
thrilled with the pivot tables in open office. That's why I thought I'd
keep Excel licenses internally (on the server and in our sales dept.
where they import the orders with my tool) and would program an
independant VB6 application accessing the XLS Files on the customer
side. My main objective is that the data flow doesn't change (xls
files), to minimize the changes in the programmation (server and sales
dept. tools would remain the same).
But if I need an Excel license to use automation on the user side, I
might as well buy Excel for all my users (even though that makes big
costs) and leave my CRM in Excel (2010 for everybody - as soon as it's
available - so some adaptation in the macros might be needed).

Now to your suggestions: I don't really want to make a huge application
for my users (i.e. parse xls files with additionnal code, which by the
way is to my opinion easier with ODBC and SQL when it goes only of
reading the cells values). Before all, I don't want the next version of
the application to be worse (or less user-friendly) than the previous
one, and I suppose the code wouldn't provide any Pivot Table
functionnality ... ?
Anyway, if I had time to make such changes, I might better rethink the
whole process and redefine the data flow (for example text instead of
xls and only data, not the application itself). The advantage of
recreating the whole user application every night is that if I add a
function to the app today, all my users have the last version tomorrow.

So as a conclusion, I'll try to put pressure so that we can buy Excel
licenses for our salesmen (and sales dept. + server). I'll just have to
hope that it'll be granted (it's a lot of money).
If it's not accepted ... then I'll have a lot of work!!!! I would then
have a deeper look at what you suggested (free code to parse xls files -
Version 2000)

Thanks again!


"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Other ways, if any, really depend on what you are doing. I don't quite
follow why you need to write to Excel files on users system if, as you
imply, the user will not need to view the files on his system. If the
objective is to create files on user1's system to be sent to user2 I
would have thought the file could be compiled elsewhere based on the
supplied data.

I don't think the ODBC approach would work, but I could be wrong.

Excel file formats are now effectively "open source", IOW the binary
formats are fully documented, and freely available for anyone to make
their own apps to read/write Excel files. For 2003 and earlier you
might look into BIFF (or BIFF8) editors. There is quite a lot of free
source code which you can integrate into your own app, but a (very)
steep learning curve. There are also commercially available app's and
dlls which should make things considerably easier, though I have not
looked into any of these.

Excel 2007 files are entirely XML, ie a zipped series of XML files. Not
sure if there are any commercial tools for read/write these.

The bottom line is you do not need Excel to read or write Excel files.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Ok thanks Peter, that's what I was afraid of.

I considered the ODBC approach, which would then be free I think. With
that, I can access and modify the data in the Excel sheets, but not
the format of the cells or other meta data included in the excel
files.

I'll see, but I'm afraid I'll have to buy Excel licenses for all my
users finally. Unless you've got other ideas?
Thank you anyway!

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Dim xlApp As New Excel.Application

That's Excel, still need a licence even if you only want to automate
it, sorry!

There might be other approaches depending on what you are doing and
the overall objectives.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Thanks Peter,

but I don't want my users to have Excel on their computers. They
don't need that.
They just need my application, but this application (written in VB6)
uses the Excel API.
Basically, my application refers to the Microsoft Excel 9.0 Object
Library.
I then use the Excel Application Object declared with this
statement:
Dim xlApp As New Excel.Application

Thanks for your help!
Jérémie

"Peter T" <peter_t@discussions schrieb im Newsbeitrag
...
Your users will need a license and key to have Excel installed on
their systems. Not sure how you would obtain Excel 9 (2000) though,
other than with an MSDN subscription.

Regards,
Peter T

"Jérémie Gent" wrote in message
...
Hi,

I've developped an application in VB6 that uses the Excel API
(Microsoft Excel 9.0 Object Library - Excel9.olb)
I need to deploy this application on many computers (for many
users) of my company who don't own a license for Excel.
Is that legal? Or do I have to buy an Excel license per user?
Basically my application will have to handle data contained in
.xls files, that's why I need the Excel API.

Thanks for your answers / links to any Microsoft page concerning
the redistribution of Office DLL.
(And if that's doable, which DLL would I have to include in my
redistribution?)

Jérémie

As Peter T pointed out, you'll need a copy of Excel in order to do
this.

--JP

On Mar 10, 3:36*am, "Jérémie Gent" wrote:
Thanks for your answer JP!

however, this is not quite what I want, cf following Note in this Article:
"NOTE: Using the methods described in this article, your users will only be
able to view your Microsoft Excel spreadsheets, Word documents, or
PowerPoint presentations. They will not be able to make any modifications to
the files"

I don't actually need my users to view the XLS Files, but I definitely need
my application to read them and write into them.

I was also thinking of accessing the xls files via ODBC, which I guess
wouldn't need any license. I wouldn't be able to change the format of the
cells though (font etc.). And If I'm not mistaken, the ODBC Microsoft Excel
Driver is in ODBCJT32.DLL which is included in standard XP Pro installation,
is that correct?

Thanks for your help!
However again for me, the best way would be to have a legal way to use the
'Microsoft Excel 9.0 Object Library' on PC without Excel license.