Prev: Late Binding worked until Access 2007
Next: Parameters on Subforms broken in Access 2007 ADP
From: Sky on 21 Feb 2010 19:36
On 2/21/2010 12:24 AM, David W. Fenton wrote:
....
>
> I'm unclear about some features, like split forms (which *are*
> useful) -- are those supported in MDB format or only in ACCDB?
>

Yes, split forms work fine in .Mdb format. And when displayed in Access
2003, they convert gracefully to normal view.

- Steve
From: RonG on 22 Feb 2010 11:13
On Feb 21, 6:36 pm, Sky <S...(a)NoSpam.com> wrote:
Good day,

And thanks for all of your thoughts.....

PW, regards Servoy...
Yes, they seem to be doing ok, from what I can tell. They recently
made a change to their IDE, moving to Eclipse, an open source IDE
enviroment, and if I remember correctly, just came out with their
newest version of the software. They seem to be able to do a lot, but
it's a complete rewrite to go from Access to Servoy. Now, that's
pretty much true of any DB to DB platform just like this. There are
tools in some cases that can assist, but in most cases, they'll move
over the tables, probably get the relationships, maybe get the forms/
reports to some extent (although from what I've seen you lose a lot of
the formatting, which means a good deal of editing, maybe more time
than it's worth), and most likely won't get the macros or modules. If
you're willing to do that, than Servoy could be a great option. But,
there is a price to be paid. Their fee structure is different than
Access in that you are paying for the runtime licenses as well as web
access, but that might be worth it. My quandary was this. I'd like
to get my product to the Mac market as well as get to something more
current than Access97. There are a couple of ways to do that. One,
work with a platform that can create a Mac executable. Access won't,
so that means something like Filemaker, Servoy, or 4D. Or, take the
system to the web and get to the Mac that way, hoping that people will
be willing to use the web rather than a desktop-based application.
That I can do by staying with Access and building a web application
some way, either by using a current standard such as MySQL/PHP, or the
MS equivalent, or moving to Access2010 and make use of their web
tools. What really sticks in me is the risk of destablizing the whole
system in the process of re-writing it in one of these other
platforms. For me, at least, I don't think it's worth the risk or the
extra time it would take. Yes, building a web app is another "start
from scratch" application if I stay with Access, but at least I've got
a working product in the meantime.

I even looked at moving to the .Net environment in Visual Studio,
which theoretically means that I could create a Mac-compatible
executable using the open source Mono project, which creates .Net
compatible builds for other OSs, but at about that point my head
exploded.

Rick, from your comments, I'm getting the idea that the runtime for
Access2007 won't run on versions of Windows prior to XP? Do I have
that right? So, in order to support those older versions of Windows,
I'd have to stay with the mdb file format? Or did I just misunderstand
that? I do kinda need to move forward from Acc97. My install scripts
are no longer supported, for example; they run, but the platform from
Wise that was used to create them isn't supported. So I need to get to
something newer, the question is, how far up the ladder do I go? Is
there a consensus as to what version of Access most developers are
using these days? I suspect it's not Acc2007.

Thanks again, and have a good day.

Ron



> On 2/21/2010 12:24 AM, David W. Fenton wrote:
> ...
>
>
>
> > I'm unclear about some features, like split forms (which *are*
> > useful) -- are those supported in MDB format or only in ACCDB?
>
> Yes, split forms work fine in .Mdb format. And when displayed in Access
> 2003, they convert gracefully to normal view.
>
> - Steve

From: David W. Fenton on 22 Feb 2010 18:15
RonG <rgafron(a)sbcglobal.net> wrote in
news:312ec314-fd20-4693-b3e0-072e2764008f(a)o3g2000yqb.googlegroups.com
:

> Rick, from your comments, I'm getting the idea that the runtime
> for Access2007 won't run on versions of Windows prior to XP? Do I
> have that right?

It's not a runtime restriction, but an Office 2007 restriction.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Tony Toews [MVP] on 22 Feb 2010 21:31
"David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote:

>And on the web front, it's also a big winner. To really benefit from
>that, you have to replace your old Access forms/reports with the new
>web versions, but it will be a familiar environment and will run
>both in the Access client and on a Sharepoint-hosted website.

Not really. Consider that using the web enabled features of A2010 might be done just
for specific forms/reports that are usable via the web. That might only be 5% or
15% fo the forms in your app.

But note that you can only use macros behind those forms. Enhanced macros with
recordset looping and so on. But nevertheless macros. And maybe it can only run on
SharePoint. Not so sure about that though.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
From: David W. Fenton on 23 Feb 2010 16:18
"Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in
news:77f6o5h7btkt3123v2j2pgl1oricvqia7a(a)4ax.com:

> "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote:
>
>>And on the web front, it's also a big winner. To really benefit
>>from that, you have to replace your old Access forms/reports with
>>the new web versions, but it will be a familiar environment and
>>will run both in the Access client and on a Sharepoint-hosted
>>website.
>
> Not really. Consider that using the web enabled features of A2010
> might be done just for specific forms/reports that are usable via
> the web. That might only be 5% or 15% fo the forms in your app.

Not sure how this contradicts what I said. You *can* create an
entire app with web forms/reports and it will reportedly run
identically in the Access client and in the web browser.

Now, if you don't want to deliver the same app to the web users as
the Access users, that's a completely different issue, one that is
orthogonal to my point, i.e., that Access now offers web support
that is going to be pretty easy for experienced Access developers to
get up to speed on. Sure, it's different, but it's not *completely*
different, as it would be if you had to use a completely different
development platform.

> But note that you can only use macros behind those forms.
> Enhanced macros with recordset looping and so on. But
> nevertheless macros. And maybe it can only run on SharePoint.
> Not so sure about that though.

So far as I've read, the macros run in the Access client identically
to the way they run on Sharepoint. At least, this is what I
understand has been promised, and without that, it would be a big
issue. From my point of view, web deployment is sufficient reason to
learn the new macros, and given that they have variables, branching
and error handling, I can't see how they are going to be that much
of a sacrifice. I guess they will still have the documentation
problem (how do you tell if a macro is in use? In VBA, you rename a
sub/function and compile, and if it's in use, the compiler will
complain; there's no such capability with macros, but I think there
really needs to be).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Late Binding worked until Access 2007
Next: Parameters on Subforms broken in Access 2007 ADP