Help......replace Access with a .NET front end and SQL Backend solution

[Anns via AccessMonster.com]

My establishment has about 20 ms access db's that will be converted over (see
subject).
When we pull all the BE's over to SQL and the FE's on Sharepoint (.net)
surely we don't have to change every user face, we should be able to use the
same FE in as before as now on Sharepoint?
ANSWER:

Conversion:

For a conversion of this magnatude, what is the most common?

i.e. - using ms access upsizing wizard for all ms access databases or use SQL
(DTS - import/export or IS)?
ANSWER:

Is this done together or it can be done in full both ways?
ANSWER:
Isn't there a simple method of upsizing/upload all the ms access FE on
sharepoint rather than having to no code (i.e. - visual studio)?

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200606/1

[Larry Linson]

I'm sorry, but I don't understand your question. If your applications are to
remain client-server, why would you consider converting the front-end to any
..NET language? Or are you talking about ASP.NET applications so they can be
used on the Internet?

The only "conversion" of Access applications to "Internet form" of which I
am aware is the Data Access Pages, which is quite limited, mostly only used
in intranets, and not much there, and which is "deprecated" in the next
version of Access. And, as it uses the browser, all the VBA in the original
application will have to be translated to vbscript or perhaps javascript.

If you wish to store your Access FE's on the SharePoint server and have
everyone execute the same copy from there, you need to be aware that the
universal advice of knowledgeable Access developers is to give each user
his/her own copy of the FE.

You might also consider reading some of the blogs which have been referenced
here and elsewhere, covering features of Access 2007, planned to be released
to corporate licensees later this year and to individuals early next year.
There has been a great deal of effort put into making it work well with
SharePoint.

Please clarify and perhaps someone can be of more help.

Larry Linson
Microsoft Access MVP

"Anns via AccessMonster.com" <u22580@uwe> wrote in message
news:62676d3a1d9ec@uwe...

My establishment has about 20 ms access db's that will be converted over
(see
subject).
When we pull all the BE's over to SQL and the FE's on Sharepoint (.net)
surely we don't have to change every user face, we should be able to use
the
same FE in as before as now on Sharepoint?
ANSWER:

Conversion:

For a conversion of this magnatude, what is the most common?

i.e. - using ms access upsizing wizard for all ms access databases or use
SQL
(DTS - import/export or IS)?
ANSWER:

Is this done together or it can be done in full both ways?
ANSWER:
Isn't there a simple method of upsizing/upload all the ms access FE on
sharepoint rather than having to no code (i.e. - visual studio)?

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200606/1

[Anns via AccessMonster.com]

Currently our ms access databases just simply sit on the company
network/server.

The goal is to take all of the db's and pull all the tables in those db's and
put them on SQL Server.
The FE will be apart of .net conversion to intranet (sharepoint). You know
instead of putting the FE on each clients computer, it now will reside in one
place.

Now the current db's we have were created by two different indiviuals that
are knowledgeable in access but not SQL or .net. So sadly for them all that
hard work they did as an owner of those databases will nowbe in the hands of
a DBA or IT related experienced person, and now they are just a user instead
of developer, IS THIS NORMALLY how it goes if the owner of the db has no sql
experience, etc?
But anyway, everyone in the company has been trained and use to using those
certain user face forms in those db's, it has been mentioned that IT will now
redesign those user face Forms/ now FE's and I was curious, surely there is a
way when the conversion happens to Sharepoint/FE to keep those user face
forms the same?

What do you mean about a copy on each client, if one FE is on the
intranet/sharepoint and people are told to access from that destination point,
why would each peron need their own copy on their computer? I realize that is
needed in other circumstances, but if the goal is access the databases in one
place (intranet - sharepoint) why is there a need to multiply them? Please
help me understand as I am truley trying to learn.
Following the question about keeping the userface the same, isn't there a way
to upload the userface/fe on these databases (be on sql) to sharepoint with
out having to program in code, the software should provide a way to pull the
already completed userfaces/forms in all of those databases to sharepoint
with out a person having to know programming language (i.e - visual studio).?

Larry Linson wrote:

I'm sorry, but I don't understand your question. If your applications are to
remain client-server, why would you consider converting the front-end to any
.NET language? Or are you talking about ASP.NET applications so they can be
used on the Internet?

The only "conversion" of Access applications to "Internet form" of which I
am aware is the Data Access Pages, which is quite limited, mostly only used
in intranets, and not much there, and which is "deprecated" in the next
version of Access. And, as it uses the browser, all the VBA in the original
application will have to be translated to vbscript or perhaps javascript.

If you wish to store your Access FE's on the SharePoint server and have
everyone execute the same copy from there, you need to be aware that the
universal advice of knowledgeable Access developers is to give each user
his/her own copy of the FE.

You might also consider reading some of the blogs which have been referenced
here and elsewhere, covering features of Access 2007, planned to be released
to corporate licensees later this year and to individuals early next year.
There has been a great deal of effort put into making it work well with
SharePoint.

Please clarify and perhaps someone can be of more help.

Larry Linson
Microsoft Access MVP

My establishment has about 20 ms access db's that will be converted over
(see

[quoted text clipped - 20 lines]

Isn't there a simple method of upsizing/upload all the ms access FE on
sharepoint rather than having to no code (i.e. - visual studio)?

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200606/1

[Larry Linson]

"Anns via AccessMonster.com" wrote

Currently our ms access databases just
simply sit on the company network/server.
Are they concurrently used by multiple users from the server? If so, you
are very lucky if you are not experiencing database corruption. Are they
separated into front-end (aka FE, queries, forms, reports, macros, and
modules) and back-end (aka BE, tables, relationships, and data)?
The goal is to take all of the db's and pull
all the tables in those db's and put them
on SQL Server. The FE will be apart of .net
conversion to intranet (sharepoint). You know
instead of putting the FE on each clients
computer, it now will reside in one place.
It will be relatively easy to move your tables to MS SQL Server.

My comments about each person having their own copy of the front-end apply
only to Access front-ends, not to applications created in .net languages.
Now the current db's we have were created
by two different indiviuals that are
knowledgeable in access but not SQL or .net.
So sadly for them all that hard work they
did as an owner of those databases will now
be in the hands of a DBA or IT related
experienced person, and now they are just
a user instead of developer, IS THIS
NORMALLY how it goes if the owner of
the db has no sql experience, etc?
It is _often_ the case. It is also often the case that those original
developers are the ones who best know the business process being served by
the DB, and that knowledge is rarely transferred (possibly not
transferrable, depending on the business) to a DBA or IT person for whom the
database and business process are only two of many competing demands on
their time. And, if the application is separated from the knowledge of the
business process, you can predict that, over time, it will become less and
less useful to the target user audience.
But anyway, everyone in the company has
been trained and use to using those
certain user face forms in those db's, it has
been mentioned that IT will now redesign
those user face Forms/ now FE's and I was
curious, surely there is a way when the
conversion happens to Sharepoint/FE to
keep those user face forms the same?
There is no "conversion" to Sharepoint FE. You will have to re-create the
application in one of the .net languages (Microsoft's are C# and VB.NET).
And, if it is truly a Sharepoint intranet, the application will likely run
in Internet Explorer or some other browser. Browsers simply do not support
the rich-client interface capabilities that Access has. The latest version
of Microsoft Visual Studio does have better support for "rich-client"
applications, but to accomplish that, you'll need developers knowledgeable
in the new features.

So, the answer is, if you really feel compelled to convert to .net, NO, you
cannot "keep those user face forms the same."
What do you mean about a copy on each
client, if one FE is on the intranet/sharepoint
and people are told to access from that
destination point, why would each peron
need their own copy on their computer?
I realize that is needed in other circum-
stances, but if the goal is access the data-
bases in one place (intranet - sharepoint)
why is there a need to multiply them? Please
help me understand as I am truley trying to learn.
That statement assumed leaving the applications in Access, and applies to
that case only.
Following the question about keeping the
userface the same, isn't there a way to upload
the userface/fe on these databases (be on sql)
to sharepoint with out having to program in
code, the software should provide a way to
pull the already completed userfaces/forms
in all of those databases to sharepoint with
out a person having to know programming
language (i.e - visual studio).?

As I explained before, Access' forms and reports cannot be "converted" to
..net languages, but must be re-implemented. So, desirable as that might be
to you, it is not an option.

If there is no _compelling_ reason to change the application FE (the user
interface) to one done in a .net language, and the "Sharepoint" intranet
actually resides on a LAN or even a fast WAN, then you might be able to
retain the Access front-ends ("user interface") with minor modifications for
the tables now being linked to MS SQL tables, so the users would not have to
learn a new interface to the applications.

Larry Linson
Microsoft Access MVP

[Anns via AccessMonster.com]

Thank you, now I understand.

I am being silly here..

I must work for you, I really enjoy this stuff (database) and could learn
alot from a great teacher as yourself.
Stand by, I have a f/u for you. I raelize you would only employ the best, but
hey the best got where they are at by some one giving them a chance....

Larry Linson wrote:

Currently our ms access databases just
simply sit on the company network/server.

Are they concurrently used by multiple users from the server? If so, you
are very lucky if you are not experiencing database corruption. Are they
separated into front-end (aka FE, queries, forms, reports, macros, and
modules) and back-end (aka BE, tables, relationships, and data)?

The goal is to take all of the db's and pull
all the tables in those db's and put them
on SQL Server. The FE will be apart of .net
conversion to intranet (sharepoint). You know
instead of putting the FE on each clients
computer, it now will reside in one place.

It will be relatively easy to move your tables to MS SQL Server.

My comments about each person having their own copy of the front-end apply
only to Access front-ends, not to applications created in .net languages.

Now the current db's we have were created
by two different indiviuals that are

[quoted text clipped - 6 lines]

NORMALLY how it goes if the owner of
the db has no sql experience, etc?

It is _often_ the case. It is also often the case that those original
developers are the ones who best know the business process being served by
the DB, and that knowledge is rarely transferred (possibly not
transferrable, depending on the business) to a DBA or IT person for whom the
database and business process are only two of many competing demands on
their time. And, if the application is separated from the knowledge of the
business process, you can predict that, over time, it will become less and
less useful to the target user audience.

But anyway, everyone in the company has
been trained and use to using those

[quoted text clipped - 4 lines]

conversion happens to Sharepoint/FE to
keep those user face forms the same?

There is no "conversion" to Sharepoint FE. You will have to re-create the
application in one of the .net languages (Microsoft's are C# and VB.NET).
And, if it is truly a Sharepoint intranet, the application will likely run
in Internet Explorer or some other browser. Browsers simply do not support
the rich-client interface capabilities that Access has. The latest version
of Microsoft Visual Studio does have better support for "rich-client"
applications, but to accomplish that, you'll need developers knowledgeable
in the new features.

So, the answer is, if you really feel compelled to convert to .net, NO, you
cannot "keep those user face forms the same."

What do you mean about a copy on each
client, if one FE is on the intranet/sharepoint

[quoted text clipped - 6 lines]

why is there a need to multiply them? Please
help me understand as I am truley trying to learn.

That statement assumed leaving the applications in Access, and applies to
that case only.

Following the question about keeping the
userface the same, isn't there a way to upload

[quoted text clipped - 5 lines]

out a person having to know programming
language (i.e - visual studio).?

As I explained before, Access' forms and reports cannot be "converted" to
.net languages, but must be re-implemented. So, desirable as that might be
to you, it is not an option.

If there is no _compelling_ reason to change the application FE (the user
interface) to one done in a .net language, and the "Sharepoint" intranet
actually resides on a LAN or even a fast WAN, then you might be able to
retain the Access front-ends ("user interface") with minor modifications for
the tables now being linked to MS SQL tables, so the users would not have to
learn a new interface to the applications.

Larry Linson
Microsoft Access MVP

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200606/1

[Larry Linson]

"Anns via AccessMonster.com" wrote

Thank you, now I understand.

I am being silly here..

I must work for you, I really enjoy this stuff
(database) and could learn alot from a great
teacher as yourself. Stand by, I have a f/u for
you. I raelize you would only employ the best,
but hey the best got where they are at by some
one giving them a chance....

I suspect you would be an excellent employee -- a major factor in gaining
knowledge is in pursuing questions until they are explained simply enough to
be understood. Alas, I am an independent consultant with no ambition to grow
my business to the point of hiring employees. I was always able to duck,
dodge, and avoid being a "payroll-card-holding manager" during my corporate
days, though I was a project manager from time to time.

Thanks for the very kind words.

Larry