I'm trying to test a strategy that I have writing dataseries values to a text file to my C directory, as I had mentioned I was doing in a former post. The only difference is that this is my second PC that has MS Excel 64 bit 2010 rather than the 32 bit version installed on my first PC.

Not sure what the error message means; however I have tested other strategies that are not writing to this file that are not producing this error.


Any ideas?

Seriously, this is not a Wealth-Lab issue altogether. Google for more (there are plenty of hits), or call Microsoft support.

Eugene, this error is only happening on the 64 bit version of Wealth Lab and not the 32 bit version.

While this may not be entirely a Wealth Lab issue, it is effecting and restricting my use of Wealth Lab Pro. I would appreciate if you would kindly help me understand the nature of this issue as I am not familiar with the help suggestions offered and I would expect that you might be better equipped to understand and explain this.

This issue may effect other users too, so I deemed it appropriate to bring it up here in the public forum and not as a separate ticketed item.

Thank you.

If you are writing dataseries values to a text file using ADO.NET technology i.e. MS Jet OLEDB 4.0, then I kindly suggest you use something much more intuitive e.g. TextWriter or StreamWriter:

C# Using StreamWriter
C# Using TextWriter

Also this solution has a benefit of being platform agnostic i.e. no use of MS Jet which is not available on 64-bit Windows. This is what the error message was telling you.

From the example that was provided below:

CODE:
Please log in to see this code.

From my strategy:

CODE:
Please log in to see this code.

and using statements:

CODE:
Please log in to see this code.

- Let me see if you can help me to understand. Based on what I have, how would I know where and what to change so as to use TextWritter vs MS Jet.

- I don't understand, and perhaps you can help me by explaining the function of MS Jet and TextWritter. Also how is textwritter available, e.g. is it a download or native in Windows.

- I'm sorry that my questions might seem, well, from an expert programmer's point of view perhaps something one aught to know from birth or early childhood. I wish I were that smart, and I do need help, so please don't think you will be talking down at me by spelling things out, but please don't pass this issue off as irrelevant or not worthy of your energy to help me fix. Ok?

QUOTE:
- I don't understand, and perhaps you can help me by explaining the function of MS Jet and TextWritter.

I'm not treating your questions from a programmer's point of view, just trying to communicate that neither we support Microsoft products nor I have the time/energy for such consulting.

If you're interested in programming in .NET languages and/or using ADO.NET (OLEDB, Ms Jet), then please use MSDN or any other applicable resource to learn about them.

MS Jet is, well, a jet and TextWriter is a golf car. You're using a desktop database engine to write text files without even knowing the difference. Yes, it's possible to read/write text files using OLEDB but what's forcing you? I can guess: the work of Steve S. (aka using SSLib)?

There's a good chance that you're not aware which part of your code is responsible for saving trades. Neither part of your code snippets contains any hint and your strategy does not seem to be using OLEDB directly. But I'm pretty sure that it's Steve's code (SSLib) that actually does, incapsulating a lot of assembly references inside the DLL. In this case, we can't help - you need to call the library developer.

Eugene, I'll you send a P.M. Mike

QUOTE:
But I'm pretty sure that it's Steve's code (SSLib) that actually does, incapsulating a lot of assembly references inside the DLL. In this case, we can't help - you need to call the library developer

We worked through the library this evening to find any reference to the MS Jet and deleted it, copied compiled and still same error. The issue is not with SSLib as you thought it might.

So I did some more investigating and found the code in the strategy makes reference to 3 external symbols, one internal Fidelity data set .SPX and 2 from Excel files, an asci format and the other the Excel data provider. I decided to do a test and change the get external symbols to .SPX only, and this made the difference.

The .DLL in question is not creating this error, but the get external symbol from Excel is. This doesn't change the fact that I can not use this program WLPro 64bit with Excel 2010 64 bit version without getting this conflict. I would like to be able to use these versions making reference to these Excel symbols I use in my systems. Is it possible and will you help me find out how?

Regarding Excel - valid point. MS Jet is used by the Excel provider and it cannot function in 64-bit environment. Which version of the provider are you using? I believe the 64-bit fix has been applied in 2010.10.

In your (now closed) ticket 19529, I provided a bugfix release in July that worked for me in Win7 x64. Excel 97/2003 files (XLS) files were loading on a machine that couldn't have MS Jet installed by design. Unfortunately, the ticket got closed next month.

Which type of Excel book are you trying to load? Excel 2007/2010 (XLSX) files will not work, and we have to live with it. However, Excel 2003 (XLS) files worked well in my testing on a 64-bit Win7 in WLD5/6 x64. Is this what you're having trouble with?

CODE:
Please log in to see this code.

Using Win 7 64 bit/ MS Office 64bit
There are two formats in Excel I am making a call for external series from. As you see above- "Indices" is a Fidelity Data Set and is not causing the issue.

"equity (daily)" is an Excel provider data set that contains a file named Equity. Equity is an.XLS ( not .xlsx, file copied from MS Excel 97 . path C:\Users\mikesblack\Desktop\Wealth Lab Equity\Equity.xls


"AjZCSV" is a data set with an ASCI file named Adj Z created in E97 and copied to my new desktop. It is as a .csv file path C:\Users\mikesblack\Desktop\AjZCSV

Let me summarize what is happening
All things being the same in the code , same data files.
Case 1:
PC 1
Windows Vista 64 bit OS
Office 32 bit
Wealth Lab v X84
Wealth Lab v64
Compiles, runs and writes to text file without error.
Case 2
PC 2
Windows 7 64 Bit OS
Office 64 bit version
Wealth Lab X84
Compiles, runs and writes to text file without error.

Case3
PC 2
Win7 64 bit OS
Office 64 bit version
Wealth Lab 64 bit version
Compiles, yes, runs with error message and without calculations.

In case 3 substituting both asci file and .xls file with a data set from Fidelity removes the problem.

Assuming that you're using v2010.10 of the Excel provider on your PCs. By the way, the bitness of Office doesn't affect anything as MS Office is not being used altogether.

What really matters is that you should have Office 2007 (or 2010) Data Connectivity Drivers installed on PC3 (and others). Can you double check that? Otherwise the provider has nothing to do but to default to MS Jet... N/A on 64-bit Windows... error.

Can you tell me how I am to distinguish each Excel provider? Where am I too look to find out where the Data Connectivity Drivers can be found?

QUOTE:
Can you tell me how I am to distinguish each Excel provider?

Extension Manager - "Other extensions".

QUOTE:
Where am I too look to find out where the Data Connectivity Drivers can be found?

You install them. They're not a part of Windows or probably MS Office too.

We discussed this recently with you and Dave Aronow, just under a different name: Accessing MS-Access 2007 (32 bit) database from Wealth-lab 64 bit. If only Microsoft listens to us I'd say it's pretty confusing, but "Microsoft Access Database Engine 2007/2010 Redistributable" and "2007/2010 Office System Driver: Data Connectivity Components" are (I believe) essentially the same file. Have you downloaded and installed the version appropriate for your Excel files?

Yes Excel Static 2010.09 on PC with Office 64 or PC #2

Yes , I did recall that conversation and as I recall had downloaded the 64 bit version from that link. But is there a way I can check to see if I did this correctly?

To be on the safe side, try installing it:

Microsoft Access Database Engine 2010 Redistributable, choose 64-bit version

You need version 2010 of the package, not 2007 - that one is locked to 32-bit.

I did reinstall and chose the 64 bit version. Seems it was there.

Not sure if this is an independent issue, but after I restarted I got the following Windows error messages on my pc. Perhaps related??
- " Can't open As10.sys"
- "memory mapping error2!"

QUOTE:
I did reinstall and chose the 64 bit version. Seems it was there.

Please try creating the DataSet based on your Excel book from scratch again. Long story short, an Excel DataSet file from a 32-bit Windows will break in 64-bit Windows and vice versa. Did that help?

I'll check and let you know.

Here's what's happening.
I created a new file - saved as a .XLS Excel 97-2003 on my desk top. Basically cut and pasted the data from the prior worksheet into the new worksheet.
Opened Data Manager from 64 bit WL
- create new Data Set
- select Excel provider
- From file I selected the file created from my deck top

- Just after this the same Error ' Microsoft.jet.OLEDB.4.0 not registered' ...

So not there yet.

OK thanks for your report. I'll check it when possible and debug to find out what happens.

Seems like I was finally able to nail this bug down and better handle the various possible OS/ACE combinations. Check your open ticket please.

This bug of our Excel static provider was fixed in build 2010.10.