473,288 Members | 1,705 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,288 software developers and data experts.

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

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
Jun 27 '06 #1
5 3573
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

Jun 27 '06 #2
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
Jun 28 '06 #3
"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

Jun 29 '06 #4
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
Jun 29 '06 #5
"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
Jun 29 '06 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

63
by: Jerome | last post by:
Hi, I'm a bit confused ... when would I rather write an database application using MS Access and Visual Basic and when (and why) would I rather write it using Visual Studio .Net? Is it as easy...
29
by: Mark B | last post by:
We have an Access app (quite big) at www.orbisoft.com/download. We have had requests by potential users to have it converted to an SQL version for them since there corporate policy excludes them...
7
by: JMCN | last post by:
Is this possible to have the 97 users with 97 front end, 2000 users with 2000 front end, 2002 users with 2002 front end, and 2003 users with 2003 front end all linked up to an access 97 backend? ...
13
by: Manuel Lopez | last post by:
I have a puzzling form timer problem that I didn't experience prior to Access 2003 (though I'm not sure access 2003 is to blame). Here's the situation: a computer has two access 2003 databases on...
35
by: robert d via AccessMonster.com | last post by:
I was asked to provide a proposal. I provided a proposal on my application and the prospective client likes what I have but is wary of it having been developed in Access. I don't understand this...
3
by: Meena | last post by:
Dear All, i have developed an application located on a server that has a front end and a back end interface, the application uses session object. when i log on as a backend user and a client user...
4
by: Anns via SQLMonster.com | last post by:
My company currently has about 20-25 Ms Access Database that they want to replace the FE with .net and the BE on SQL. This will be done using Visual Studio 2005. Once the FE is converted to...
8
by: rdemyan via AccessMonster.com | last post by:
I've converted my application from A2K format to A2003 format. I tried to follow Allen Browne's protocol in getting my app into A2003 (although I was unable to find informtion on the conversion...
10
by: Les Desser | last post by:
In article <fcebdacd-2bd8-4d07-93a8-8b69d3452f3e@s50g2000hsb.googlegroups.com>, The Frog <Mr.Frog.to.you@googlemail.comMon, 14 Apr 2008 00:45:10 writes Thank you for that. It was very...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.