none
convert vba to macros

    Question

  • Yes, this question is in the right order: VBA -> macros. In order to move an Access database to SharePoint, VBA is no longer an option.

    Is there a converter out there yet?


    peter n roth - http://PNR1.com, Maybe some useful stuff

    Monday, February 18, 2013 7:07 PM

Answers

  • I don't know such tool as of yet. Moreover, I hope you understand that Macro language is much more limited than VBA. Thus the very frequent message from such converter would be "*** command can't be converted to macro language because it isn't supported there". 

    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru

    • Marked as answer by Peter N Roth Tuesday, February 19, 2013 3:02 PM
    Monday, February 18, 2013 7:22 PM

All replies

  • I don't know such tool as of yet. Moreover, I hope you understand that Macro language is much more limited than VBA. Thus the very frequent message from such converter would be "*** command can't be converted to macro language because it isn't supported there". 

    Andrey V Artemyev | Saint-Petersburg, Russia
    Russian blog artemyev.biztoolbox.ru

    • Marked as answer by Peter N Roth Tuesday, February 19, 2013 3:02 PM
    Monday, February 18, 2013 7:22 PM
  • The  feature does not exist because it is not possible.

    The problem is macro code for Access web has to run INSIDE of your browser. Last time I looked a browser running on your IPad does not have recordsets, and in fact has FEW VBA functions. So the macro code you write MUST be able to run on that Apple iPad.

    However, you can consider just sending tables up to SharePoint, and KEEP USING your VBA front ends. You can then deploy that Access application on any computer with an internet connection and everyone will be updating the same database.

    it not clear if you looking to just send  your data up to SharePoint and continue to use your VBA application? (you can MOST certainly do this).

    However, if you are looking to create a 100% web browser based, then there is no automated conversion, and the problem is as noted that web browsers don't have VBA features like record sets. So macro code you write in a Access Web form HAS to run in other web browsers such as Firefox or Safari – your macro code is limited to what features those web browsers have, and thus no automated conversion is possible.

    So do distinguish between moving your data into SharePoint and continuing to use your existing VBA application as opposed to a re-write as web based.

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Monday, February 18, 2013 9:21 PM
  • @Andrey – yes, I understand there are limitations. If such a converter recognizes VBA constructs, then the message would more likely be “here is the original Subroutine” followed by the text, followed by “here is the equivalent macro” blah di blah. And in some cases followed by “we tried and gave up.”

    @Albert – When you see the tool and use it, you will believe in the possibility.

    My belief comes from experience (ancient though it is) with Fortran, ratfor, struct, and beautify. Struct reads Fortran, passes it to beautify, and produces ratfor. The ratfor program (rational fortran) reads ratfor code and produces Fortran. Perhaps needless to say, ratfor is easier to read and write than Fortran; it’s more like C.

    What I want to avoid is using Access front ends. What I want is the browser interface for my users. SharePoint promises such an arrangement, and will accept data macros, but not VBA. Well, that’s what Microsoft advertises, anyway.

    So SOMEBODY should get to work out there!


    peter n roth - http://PNR1.com, Maybe some useful stuff

    Monday, February 18, 2013 11:36 PM
  • All I am saying that you cannot convert a steam power engine to run on electricity – you have to re-build how the engine works. And if you do get the steam engine to run on electiry, the results are just so poor as to not be worth the effort.

    The problem is not converting VBA code to macro, the problem is that code has to run inside of your web browser. Last time I looked, there are no record sets inside of a browser. Macro or VBA code that uses record sets is simply not a possible when running in a browser.  This ALSO explains why macro code in a web forms does NOT allow use of record or table processing – that code needs to be placed and run on the server side – not inside of the browser.

    This is NOT just a syntax change. There has often been converter systems that will convert Pascal into C++ for example.  (and they work quite well).

    The problem here is not conversion of syntax, but that the two systems work differently. This is why for example there never was an automated conversion of DOS programs to windows programs – it was not the just the fact of a mouse, but the underlying technologies were too different.

    So, I suppose something that would have converted DOS programs to windows was possible, but the results were so poor, and the cost of such a system would have been too high, in fact the cost was higher than the HUGE payout that someone would have received for creating such an automated conversion program.

    In other words, if the need and payoff is so great, then why would someone not create such a program and become the next Bill Gates?

    I think everyone has come up with the idea of an automated conversion system from windows to web and if you can, then you will be the next billionaire. The problem is not the idea, the problem is such a conversion is not practical.

    Flying cars are possible today, but they are just not practical – same thing for such automated conversions. Possible yes, but not practical.

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Tuesday, February 19, 2013 12:08 AM
  • @Albert – from what I’m reading of SharePoint, if I state it correctly, the Access database is hosted in a SQL server database that maintains SharePoint lists. The macros run there, not in the browser. SharePoint processes the lists with ASP.NET to present HTML to the surfer. Probably a bunch of other browser oriented stuff as well.

    Going TO the site, the Access “Export Tables to SharePoint” wizard does the table conversion, and translates the data macros as well.

    ---

    Now there IS also the possibility to run VBA in the client, which requires Access on the “front end”. But the idea of front end is changed by the SharePoint model.

    And by the way, speaking of billionaires, Microsoft does fall into that category.


    peter n roth - http://PNR1.com, Maybe some useful stuff

    Tuesday, February 19, 2013 2:34 AM
  • It depends on what kind of macro you are writing. ANY code you write in a form is converted to JavaScript and runs CLIENT side in the browser. As I stated, this explains why forms code you write does not have the ability to update tables.

    If you want to run code that updates tables, then you need to call + use server side code. So it depends on what kind of macro you are talking about. So of course writing a table macro runs server side since that is where the table resides.

    The term used to distinguish these macros are:

    UI macro – any macro code written in a form (or any saved macro in the macro category that is called from a form – this code runs browser side and thus runs on your iPad or Smartphone).

    Data macro – any macro run via a table trigger or any saved "named macro" that is called by a trigger. Both table trigger macros and UI macros can call named macros.

    So you have to be clear as to what kind of macro you are talking about, but any code you write in a form simply runs inside of the browser and this explains why the function set is so limited inside of a form. There are some cool tricks  you can use to get use of Hour(), or Minute() functions in a form, but you will notice how such functions are missing in UI macro, but they ARE available in a data macro (since that code runs server side has NEAR the same function set as VBA functions).

    The setup is like this:

    So any code you write in a form runs on the left side - and it runs as JavaScrip LOCAL to the browser without round trips to the server. You execute a MsgBox("Hello") and that code does NOT hit the server, but is 100% browser side code.

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada


    Tuesday, February 19, 2013 4:17 PM