Hi. I'd like to use a few VBA commands that I'm not really sure how
to use with Sharepoint. For example, I'd like to calculate the number
or working days and display each of them on a form.

Is any of this possible? Also, is there a solution that can convert
an existing database without having to convert everything to the
pointless macro route -- and this, using Sharepoint.

Thanks!

Cindy

"Cindyc100" wrote in message
news:a73fd767-00cb-4edb-87bf-d229a7318ed0 (AT) a10g2000vbz (DOT) googlegroups.com...

Are you talking about publishing an Access database and web forms? If you
send the tables to SharePoint, you are still free and able to use VBA in
your forms.

If you talking about a web based form, then you are correct, you cannot use
VBA. And, unfortunately there no automated converter for regular forms to
web forms.

However, it not clear now how you calculate working days (and from what
date). There are number of ways to accomplish this type of calculation from
a web form. One possible approach is to have a table routine do the
calculation when the record is saved (you write a new store procedure in the
table, and then when the record saved, then the code runs, and then saves
the number of days). This would then allow you to simply display the value
in a form (or report) without the need to run code when you browse or
display records.

So, this is possible and there is several approaches here. While most
approaches will require you to write some macro code, you might also be able
to consider a application with both web parts and parts that will continue
to use existing VBA code. So, then perhaps one modifies the VBA form to save
the working days calculation in the table, and then this value would then be
available in the web based forms also. This kind of approach may, or may
not work for your case. So in some cases, if only parts of data some entry
will occur in the web parts, then this data can then be processed and used
by the client VBA parts with the days work calculation for further
processing.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

On May 16, 3:26*pm, Cindyc100 <cindyc... (AT) hotmail (DOT) com> wrote:
Cindy,

In order of "least painful" to "highly customized"...

There are Calculated Fields. Which can handle almost all of the
typical "Excel" commands, and as such, and get into some pretty
complex nested conditional statements.

There are WorkFlows. Which you can create through SharepointDesigner
(free download). These are somewhere between a "pointless macro" and
VBA. Tough for me to get my arms around. And there's always a lag in
their calculations.

There are also ways to use javascript to replace parts of your HTML
with calculations. These work. And we use them. But, to be honest,
they are somewhat UGLY hacks when you get right down to it since it's
all client side. That introduces having to check for browser
compatibility, etc. However, they work great. Use a Rich Text
Content webpat, and "link" to the .js file when you edit the page.

Finally, you can create custom controls within sharepoint that do all
sorts of magical things. But, get out your C# and be prepared to have
fun.

"jonceramic" wrote in message
news:a3a2e168-bd64-485a-8f87-92b0ca69f3c1 (AT) j28g2000vbp (DOT) googlegroups.com...


I would think the path of least resistance here would be to create a named
data macro in Access that does the calculation and processing. This code
will thus run and reside server side, and can be called from a Access web
form (which any code written in that web form runs client side as
JavaScript). And that named macro can be called from a Access table trigger.
Since a data macro can do record processing, it would seem that such a
choice would be the path of least resistance.

And even better is that macro could also be used for long time VBA
applications also.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

On May 18, 10:54*pm, "Albert D. Kallal"
<PleaseNOOOsPAMmkal... (AT) msn (DOT) com> wrote:
I'm still stuck on Access2003. Sounds like I have some new
options when we finally go to Access 2010 later this year!

Does this mean I can link to an Oracle table in Access2010, then make
a form in Access 2010 that uses it, and then publish that to
Sharepoint? (hope hope)

Jon

"jonceramic" wrote in message
news:1769cde3-f98f-42dc-b528-11da1ee63e3d (AT) s14g2000vbi (DOT) googlegroups.com...


No, (at least not yet!).

Unfortunately because you're running a web server and web site, the oracle
data is sitting on another server on another site/computer. As it stands
right
now, such connections are not allowed.

However, In fact it turns out that SharePoint has a really incredible
feature called the BDC (business data connectivity). Think as BDC as a
really incredible kind of web based ODBC on steroids. In fact this system
allows you to write your own .net providers that allows you
to connect to virtually any kind of data source. Even a text file on the
server
if you wanted. As long as this "thing" can be exposed and displayed as a
table,
then SharePoint will consume and view that data as a standard list in
SharePoint.
So, tables used with Access + SharePoint, are actually called lists.

So the linking and setting up and connecting to these other data sources
such as
oracle would have to occur on the SharePoint site. Unfortunately this
great feature called BDC does not current work with Access Web.

I'm pretty much hoping that this feature will appear in the next version of
access, as it means then you
could set up data sources within your organization to oracle, sap, MySQL,
SQL
server, exchange, and even web services could all be used with Access Web
as long as it exposed the data in some type of table format.

Aimee access is have a long tradition of being able to connect to many
different types of data sources, and this would give us the same ability
within sharepoint, and would open up tremendous amounts of doors for
connecting to different systems within an organization, but utilizing them
with access.

As noted, right now SharePoint has BDC support, but unfortunately it doesn't
work with the access web services (the feature was cut during the beta
trial ).

So currently the only data source you're allowed to use with access web
applications are the actual tables that you publish to the same site.

However you can get a little bit creative and use a client based access
application to get around some of these limitations. Access is always been
a great tool that allows you to connect to many different Data sources. So
for example if you have a main customer file sitting on SQL server, you
could launch up a customer record form, and when you do so you could have
some code to check if the web based part of the system has any new
information or updates available for that particular customer in question.
If there is some data, the data could then be pulled from the SharePoint
site into SQL server at this point in time. So you can still cobble together
some types of setups of general procedures in which data does get moved
around between part from the web system into SQL server for example.

So often, sometimes just shut when data around between the different servers
will suffice in these cases, and often can result in a more secure system
anyway. (so you might pull some data from a cloud based system into one a
longtime existing legacy access application for example - and an application
which the data is offline and not from the cloud.

So the access client application (even ones that you publish to SharePoint)
can still connect to multiple data sources including an
access web publish database. Unfortunately for the time being however the
access web applications (web forms) are restricted to the data within the
particular web site.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com