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" <jer_...@hotmail.com> 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" <(E-Mail Removed)> schrieb im Newsbeitrag
news:e23e43eb-2e1c-45db-a39a-(E-Mail Removed)...
Here's a start:

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

--JP

On Mar 9, 11:04 am, "J r mie Gent" <jer_...@hotmail.com> 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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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
> news:(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> 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
news:(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> 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
>> news:(E-Mail Removed)...
>>> 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" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> 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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
> news:(E-Mail Removed)...
>>> 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" <(E-Mail Removed)> wrote in message
>> news:%(E-Mail Removed)...
>>> 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
>>> news:(E-Mail Removed)...
>>>> 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" <(E-Mail Removed)> wrote in message
>>>> news:(E-Mail Removed)...
>>>>> 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
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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
>> news:(E-Mail Removed)...
>>>> 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" <(E-Mail Removed)> wrote in message
>>> news:%(E-Mail Removed)...
>>>> 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
>>>> news:(E-Mail Removed)...
>>>>> 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" <(E-Mail Removed)> wrote in message
>>>>> news:(E-Mail Removed)...
>>>>>> 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" <(E-Mail Removed)> wrote in message
news:OJu$(E-Mail Removed)...
> 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
> news:(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> 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
>>> news:(E-Mail Removed)...
>>>>> 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" <(E-Mail Removed)> wrote in message
>>>> news:%(E-Mail Removed)...
>>>>> 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
>>>>> news:(E-Mail Removed)...
>>>>>> 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" <(E-Mail Removed)> wrote in message
>>>>>> news:(E-Mail Removed)...
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>