By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,659 Members | 940 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,659 IT Pros & Developers. It's quick & easy.

Tool to export MS Access forms, queries, tables, and (eventually) code

P: n/a
Looking to see how many people could use this kind of tool.

I've got several large databases I've developed in Access with MySQL as
the back-end.
I've started using Linux instead of windows and the only thing I can't
migrate is my Access databases.

I'm looking to export them in a standard file format, then provide
convert functionality into SWT, Flash, HTML, Native and/or some other
formats.

The other benefit would be the users would no longer need Access
installed to use the databases.

If you are interested in this kind of a tool, please reply here.

Thank you!

Jul 3 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
<dt*********@gmail.comwrote
Looking to see how many people
could use this kind of tool.

I've got several large databases I've
developed in Access with MySQL as
the back-end.
I've started using Linux instead of
Windows and the only thing I can't
migrate is my Access databases.

I'm looking to export them in a standard file format, then provide
convert functionality into SWT, Flash, HTML, Native and/or some other
formats.
As I don't believe any of the tools you list even remotely could be
considered comparable to Access, I think you'd find "conversion" rather
difficult. If you are going to convert, it's probably going to have to be in
one of the progamming languages than Linux supports, e. g., C, Java, Perl,
PHP, Ruby, Kylix, etc.. There's just no comparable development tool to
Access in that world, AFAICT.
Jul 4 '06 #2

P: n/a
On Tue, 04 Jul 2006 02:27:52 GMT, "Larry Linson"
<bo*****@localhost.notwrote:

And before you think "I'll EVENTUALLY tackle the code", consider how
few applications run without code.
And before you think "My tool still does x% of the work even without
code conversion", consider that most potential users of such product
are not coders, so they'll see little value in a product that doesn't
take them all the way. Just talk to MSFT about the success (ahem) of
their VB6 to VB.NET conversion tool...

-Tom.
><dt*********@gmail.comwrote
Looking to see how many people
could use this kind of tool.

I've got several large databases I've
developed in Access with MySQL as
the back-end.
I've started using Linux instead of
Windows and the only thing I can't
migrate is my Access databases.

I'm looking to export them in a standard file format, then provide
convert functionality into SWT, Flash, HTML, Native and/or some other
formats.

As I don't believe any of the tools you list even remotely could be
considered comparable to Access, I think you'd find "conversion" rather
difficult. If you are going to convert, it's probably going to have to be in
one of the progamming languages than Linux supports, e. g., C, Java, Perl,
PHP, Ruby, Kylix, etc.. There's just no comparable development tool to
Access in that world, AFAICT.
Jul 4 '06 #3

P: n/a

Larry Linson wrote:
<dt*********@gmail.comwrote
Looking to see how many people
could use this kind of tool.
>
I've got several large databases I've
developed in Access with MySQL as
the back-end.
I've started using Linux instead of
Windows and the only thing I can't
migrate is my Access databases.
>
I'm looking to export them in a standard file format, then provide
convert functionality into SWT, Flash, HTML, Native and/or some other
formats.

As I don't believe any of the tools you list even remotely could be
considered comparable to Access, I think you'd find "conversion" rather
difficult. If you are going to convert, it's probably going to have to be in
one of the progamming languages than Linux supports, e. g., C, Java, Perl,
PHP, Ruby, Kylix, etc.. There's just no comparable development tool to
Access in that world, AFAICT.
Thankfully PureBasic works in Linux for the development of the tool and
SWT (used by Eclipse) is available to build the form GUI.

Most work would be in putting the two together. The idea isn't to
replace Access for the developer, but to provide a way to convert the
resulting front-end to a format end-users can use without having to use
windows and access.

Jul 4 '06 #4

P: n/a
You're right about the code part. It would be difficult to automate
that conversion as the GUI objects would be accessed differently than
the Access form objects. It's not an impossible conversion though.
This seems like one of those ideas that is 90% doable, but the
remaining 10% would break the success.

Tom van Stiphout wrote:
On Tue, 04 Jul 2006 02:27:52 GMT, "Larry Linson"
<bo*****@localhost.notwrote:

And before you think "I'll EVENTUALLY tackle the code", consider how
few applications run without code.
And before you think "My tool still does x% of the work even without
code conversion", consider that most potential users of such product
are not coders, so they'll see little value in a product that doesn't
take them all the way. Just talk to MSFT about the success (ahem) of
their VB6 to VB.NET conversion tool...

-Tom.
<dt*********@gmail.comwrote
Looking to see how many people
could use this kind of tool.
>
I've got several large databases I've
developed in Access with MySQL as
the back-end.
I've started using Linux instead of
Windows and the only thing I can't
migrate is my Access databases.
>
I'm looking to export them in a standard file format, then provide
convert functionality into SWT, Flash, HTML, Native and/or some other
formats.
As I don't believe any of the tools you list even remotely could be
considered comparable to Access, I think you'd find "conversion" rather
difficult. If you are going to convert, it's probably going to have to be in
one of the progamming languages than Linux supports, e. g., C, Java, Perl,
PHP, Ruby, Kylix, etc.. There's just no comparable development tool to
Access in that world, AFAICT.
Jul 4 '06 #5

P: n/a
"DTecMeister" wrote
Thankfully PureBasic works in Linux
for the development of the tool and
SWT (used by Eclipse) is available to
build the form GUI.
IIRC, PureBasic is a classic Basic that generates "programs"... may be fine
for the tool. Even in end-user-created applications, there's a lot of VBA
"snippets" that execute on events, such as OnFormOpen, OnFormClose,
BeforeUpdate... merging that with the Forms in a "classic Basic program" is
going to take a lot of work, even if PureBasic has the necessary
functionality.
Most work would be in putting the
two together. The idea isn't to
replace Access for the developer, but
to provide a way to convert the
resulting front-end to a format end-users
can use without having to use
windows and access.
Oohwee, if you want to re-create just the end-user user interface, remember
there are more person-hours in Access than you really want to count. They
have development _teams_ at Microsoft, and often they are not small ones --
also remember that each of those teams had a year or more to work on their
target release. So, there's a lot of "catching up" to do.

If you find a tool, or if you build one, I hope you will report here,
because we get questions regularly (though not in large quantities), about
Access on other platforms, or "equivalent DB software" on other platforms.

Larry Linson
Microsoft Access MVP
Jul 4 '06 #6

P: n/a
I agree with all your comments here Larry. Thanks for the quick reply.
It looks like it may be wise (if the decision is to procede) to
develop the equivalent DB software first then worry about the
conversion process.

Larry Linson wrote:
"DTecMeister" wrote
Thankfully PureBasic works in Linux
for the development of the tool and
SWT (used by Eclipse) is available to
build the form GUI.

IIRC, PureBasic is a classic Basic that generates "programs"... may be fine
for the tool. Even in end-user-created applications, there's a lot of VBA
"snippets" that execute on events, such as OnFormOpen, OnFormClose,
BeforeUpdate... merging that with the Forms in a "classic Basic program" is
going to take a lot of work, even if PureBasic has the necessary
functionality.
Most work would be in putting the
two together. The idea isn't to
replace Access for the developer, but
to provide a way to convert the
resulting front-end to a format end-users
can use without having to use
windows and access.

Oohwee, if you want to re-create just the end-user user interface, remember
there are more person-hours in Access than you really want to count. They
have development _teams_ at Microsoft, and often they are not small ones --
also remember that each of those teams had a year or more to work on their
target release. So, there's a lot of "catching up" to do.

If you find a tool, or if you build one, I hope you will report here,
because we get questions regularly (though not in large quantities), about
Access on other platforms, or "equivalent DB software" on other platforms.

Larry Linson
Microsoft Access MVP
Jul 4 '06 #7

P: n/a
Access forms expose one extra set of properties, the
properties shown on the properties form as 'events',
which expose the links between the UI object and the
code object.

Why is using active x objects so painful with Access?
Because they don't expose 'event' properties for their
methods, their methods don't show up on the Access property
sheet. Instead, you have to go into VBA to find the methods,
and use VBA code to link the event source to the event sink
for each method/event.

Although another tool will not necessarily have an 'event'
property (Delphi does), any set of tools that produce com
interfaces will allow you to match up event sources and
event sinks.

A translation utility doesn't have to expose the link in
a property sheet.

The same considerations apply if you use another object
interface instead of com.

(david)

"Larry Linson" <bo*****@localhost.notwrote in message
news:dunqg.7052$0G2.5778@trnddc07...
"DTecMeister" wrote
Thankfully PureBasic works in Linux
for the development of the tool and
SWT (used by Eclipse) is available to
build the form GUI.

IIRC, PureBasic is a classic Basic that generates "programs"... may be
fine for the tool. Even in end-user-created applications, there's a lot
of VBA "snippets" that execute on events, such as OnFormOpen, OnFormClose,
BeforeUpdate... merging that with the Forms in a "classic Basic program"
is going to take a lot of work, even if PureBasic has the necessary
functionality.
Most work would be in putting the
two together. The idea isn't to
replace Access for the developer, but
to provide a way to convert the
resulting front-end to a format end-users
can use without having to use
windows and access.

Oohwee, if you want to re-create just the end-user user interface,
remember there are more person-hours in Access than you really want to
count. They have development _teams_ at Microsoft, and often they are not
small ones -- also remember that each of those teams had a year or more
to work on their target release. So, there's a lot of "catching up" to
do.

If you find a tool, or if you build one, I hope you will report here,
because we get questions regularly (though not in large quantities), about
Access on other platforms, or "equivalent DB software" on other platforms.

Larry Linson
Microsoft Access MVP

Jul 4 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.