I have a excel workbook. I need to show it as a HTML page that will be refreshed automatically(say every 2 minutes). For that i need to run the calculations on every sheet and then save as HTML. I will figure out later how to swap the new HTML file for the old one later. I already have a macro in excel that does all the calculations and then saves as HTML every 2 min. All i need to do is call that macro
The problem is that the machine on which all this is to take place is a server machine and thus MS office cannot be installed on it. Thus i cannot use Excel COM Inter-op.
One was is if i could write a .net program or a Vb Script that will run the macro. But a .net program always uses inter-op.
Another way is if i could save the book as a HTML and run the macro in the HTML itself(Dont know if the HTML has the VB A code). Here also i found that i require Visual Basic Editor which i cant install( as it comes with excel only).
I would prefer not to use third party soft wares.
Can any of the above two procedures be implemented in the given conditions? if not is there any other way?
UPDATE:
Have been looking into open XML for a solution and have finally found that open XML 2.0 cannot run excel calculations as the SDK does not have the calculation engine. Does open XML SDK 2.5 have the calculation engine??
In short: You cannot run a macro without Excel installed. Worse: You should not intsall Excel on a Server. It is not recommended and impossible to do this in a stable way.
My best bet would be something like this: Use a :net library which can read xlsx files, like EPPLUS and "translate" this macro into net, which the EPPLUS library as its foundation. Also, this is a lot fastrer than Interop (factor 10 - 100) and fits better into a Server infrastructure with ASP.NET (for example).
Have you considered putting the macro as a .NET Managed AddIn on a shared machine, executing the macro from the server using a shell command to open Excel on the shared machine and the macro runs on Open.
Then you can get the macro itself to export the data to HTML and copy the pages to your server.
As has been said, avoid installing Office on a server (though it has been done in the past, it's never advisable)
Most robust option would be to re-write your vba in .NET as a .NET Managed AddIn - then you have more control over processes, but as has been pointed out, NOT on a Server.
Thanks for the resonses. Found a way to show the excel as HTML in the given conditions.
Just FYI, I used a project known as NPOI. It is the .net version of POI used in java. It allows me to open edit and save excel workbooks without installing excel. plus it is opensource so i customized it according to my requirements.
https://npoi.codeplex.com/
https://github.com/tonyqus/npoi
Related
Im getting this error when running an SSIS project that moves all of our files from FoxPro into SSMS Dbs. The corresponding DBF file opens fine on FoxPro and the memo field which is the FPT file to knowledge works fine too, So I don't what the solution is, I tried making a little changes to the memos to see if that would update the file but that didnt work. I tired re indexing the DBF but no luck there either. How can i generate a new FPT file so I can run this project. How could it be invalid. There is no support online for this.
You are using a third party .NET tool (RatSql.DbfReader). Judging from the exception message this tool was written in a .NET language. It's not a Microsoft product and not part of Visual FoxPro.
DBF files are a family of formats that are similar but have subtle differences. Many tools that claim to support DBF files, will only support DBF files created by certain products, such as VFP 6, FP 2.6, dBase or Clipper.
The options I see for you:
Get in contact with the vendor and make sure that Visual FoxPro tables are supported by their product. They might have an update or can suggest alternative solutions.
If this is an in-house developed product you need to get into touch with the original developers.
Since you have Visual FoxPro, you can convert the file to an older version using the following commands:
USE table
COPY TO newTable TYPE FOX2X
replace table with the path and name of the DBF file, and newTable with the path and name of a new file. Then use the new file for your import. There's no guarantee this works, but the old FoxPro 2.x format is more likely to be supported by third party libraries.
If this is a repeated process, you can compile these commands into an EXE file and incorporate calling the EXE into your import process.
Replace the .NET component with the Visual FoxPro ODBC driver or OLEDB provider. The ODBC driver does not support features introduced after VFP 6, but should work in most cases. Both are only available as 32-bit drivers which might require you to use 32-bit tools to connect to the DBF file.
It might actually be a problem with one ore more records where the pointer to the memo field is wrong. You can find this with Visual FoxPro. Open the DBF file in Visual FoxPro and then open a Browse window. You can do this interactively in the menu or by executing USE and BROWSE commands.
Then double click the column saying "memo" or "Memo". If there are multiple columns, you need to repeat the following step for every column. Now click on the BROWSE window's title bar and hold down the down arrow key. Visual FoxPro should begin scrolling through the table and displaying every record. If there is an error in the memo field, you will get an error message.
Alternatively you can write a FoxPro program that uses a SCAN...ENDSCAN loop and accesses every memo field with =memofieldname if there are too many rows in the table to do this interactively.
I have a very large amount of code written in VBA in Access .mdb files, containing forms and connecting to an Access data base. I need to migrate this code to a VB6 application. It isn't practical to rewrite all of it as there is just too much.
Is there a way to call that VBA file from a VB6 form with buttons, that would allow users to launch each one of these VBA modules, via a simple click on its corresponding button? What line of code in VB6, allows to launch a VBA file?
Update
I finally succeeded to figure out how to launch a VBA mdb file from my VB6 form using this instruction :
Call Shell("C:\Program Files (x86)\Microsoft Office\OFFICE11\MSACCESS.EXE C:\presto.mdb /runtime /cmd", 1)
So the VBA project is now launched from the VB6 form, but it crashes, at start up, showing this error "Runtime error ‘3024’ Could not find file ‘C:\db.mdb’".
I feel like I'm half way to thee solution. But I don't know what am I missing here?
Without knowing the structure of your VB6 application and your access files and what they do, it is virtually impossible to give any sort of useful answer.
What you want to do is not easily possible, as stated in comments VBA projects are not designed to work in this way.
However here are some suggestions.
Investigate the RunMacro command and see if this is of use to you.
You could try to use a tool like autohotkey to record mouse clicks where you want them and replay from your VB6 app.
Look at pulling out sections of VBA that are business logic and directly copy and paste code into your VB6 app. This may or may not work depending on the code.
Begin the slow process of rewriting (but don't rewrite in VB6, use VB.Net, C# or do a web app or something at least resembling a 2015 application).
If you want my honest advice begin to migrate to a more modern solution such as VB.NET so you won't have an even worse problem in 2020.
There is NO silver bullet for your problem.
It would be better to design a new form in VB6 with button as you said but also with some text(s)/list(s)/whatever(s) you want to display the results, then you copy/paste VBA code into button_click(s) event(s) to execute it and add to that vba code some output to the text(s)/list(s)/whatever(s) you decided to put on the VB6 form.
Edit : Ok, so taking your comment in consideration perhaps that trick could help avoiding re-write thousands of line code : add in the VBA code a while loop that trigger some Sub or Function on the presence of a flag on the system (a specific c:\temp\fileFlag.txt for example) so as soon as it appear the VBA code is called... if the VB6 control the flag would it do the job ? :)
We're running Microsoft Dynamics CRM 4.0, and setting up custom JavaScript event handlers on several of our forms.
I'd like this JavaScript code to be kept under revision control, but I'm not aware of any way of deploying changes to these scripts, other than manually editing (or copy/pasting) the code in the Dynamics CRM entity customisation forms - which means it would be all too easy for someone to make changes to the running system and 'forget' to copy/paste their changes into the revision-controlled version.
I'm wondering if we can use something like a trigger or a FileSystemWatcher component to catch changes to these files and make sure they're stored in revision control - but I have no idea where to find the actual raw scripts. Are they stored somewhere in the MSCRM_CONFIG or MyCompany_MSCRM databases? Or on disk somewhere on the CRM server itself?
Thanks!
It's basically included in the FormXML which is the definition of all forms in your environment. It is stored as part of the organizationui.
See also http://social.microsoft.com/Forums/en-US/aaa6f404-81eb-467d-b9bb-3d29108ec92b/where-does-crm-40-javascript-code-get-stored-in-database
The JavaScript is stored inside the database, I can't find the exact table for CRM 4.0 (here an article about CRM 2011 location just for your information http://kellyhoang.blogspot.com/2012/01/crm-2011-customization-decript-default.html)
There is also a tool for extracting the JavaScript from a CRM 4.0 instance, you can find it here:
http://blogs.infinite-x.net/2011/09/30/export-javascript-crm-4-0-updated/
(you can decompile it to look how it works, or ask the author directly)
I am about to release an Access Database application where the UI is used exclusively to interact with the database tables.
Whilst I am interacting with the forms during run time, the Visual Basic Editor appears with a line of code highlighted in debug mode, even when no breakpoints exist and no run time error has occurred.
Has anyone else come across this issue?
I need to ensure that the editor does not appear (under normal operating conditions) while the user is interacting with the application.
Thanks.
Yes, I have had this problem too and it has driven me batty. The quick and dirty way of fixing it is to create blank database and import all of the objects from you old database into the new one.
Are your users working with an .accdb file? (or .mdb, depending on the Access version)
If yes, you should convert it into an .accde/.mde before giving it to your users.
Quote from the link:
Additionally, if the database design needs to be secured to prevent changes, Access databases can be locked/protected (and the source code compiled) by converting the database to a .MDE file. All changes to the VBA project (modules, forms, or reports) need to be made to the original MDB and then reconverted to MDE. In Access 2007 and Access 2010, the ACCDB database is converted to an ACCDE file. Some tools are available for unlocking and "decompiling", although certain elements including original VBA comments and formatting are normally irretrievable.
--> since .accde/.mde files are compiled, it's not possible to view the source code at all.
So the VBA editor can never appear accidentally like you experienced...be it because of a breakpoint, some Stops in the code or some strange breakpoint error like yours.
Using Script Task, I have written a code to create a folder and create a MS Word document inside the newly created folder. It is working on the local machine but it is not working on the server where the package is deployed to. The folder is created successfully, but the Word document file is not created. For Word document creation, I had to refer another DLL where I had included an additional namespace Microsoft.Office.Interop.Word. Is there anything else to do before deployment ?
Based upon rfonn's comments, your choices are as follows:
Install Word 2007 on the server.
Re-do your package on a dev box with Word 2003 installed and deploy to your server.
Use some other tool to generate the Word Document.
SSIS is generally used for movement of data, so while it is possible to do what you are doing, it is likely not the best tool for the job. If you are capable of writing code in a script task to do what you want in SSIS, it is possible to write a program (VB or C# or any other tool you choose) to do the same thing without SSIS being wrapped around it. My money is on option #3 being your best choice.
I guess you missed installing the Office PIA.
After installing the relevent PIA according to your Office version, add a reference to microsoft.office.interop.word (.NET) file in your project (ssis script in VS).