473,569 Members | 2,770 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Help......repla ce 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.c om
http://www.accessmonster.com/Uwe/For...ccess/200606/1
Jun 27 '06 #1
5 3599
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.c om" <u22580@uwe> wrote in message
news:62676d3a1d 9ec@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.c om
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.c om
http://www.accessmonster.com/Uwe/For...ccess/200606/1
Jun 28 '06 #3
"Anns via AccessMonster.c om" 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
transferrabl e, 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.c om
http://www.accessmonster.com/Uwe/For...ccess/200606/1
Jun 29 '06 #5
"Anns via AccessMonster.c om" 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
5842
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 in Visual Studio to create reports and labels as it's in Access?` The advantage of VS.net is that not every user needs Access, right? And that...
29
3676
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 from buying mdb backends. Here's the (million dollar?) questions :) How long and how difficult a process would it be? Which SQL platform would...
7
2462
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? We are currently planning on upgrading workstations with either 2000, 2002, 2003. the criteria for the specific version will depend on the IT...
13
7460
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 it, a frontend and a backend. Case 1: If vba code on the frontend updates many rows (360,000) on the backend, a form's timer event (from the...
35
2533
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 concern since my front-end application will be linked to a SQL SERVER backend. But there seems to be this "conventional wisdom" among IT people...
3
1402
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 form the same computer, the sessions conflict together and i get unexpected results, and i found out that this happenes when one of the sessions...
4
4275
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 .net and the BE is SQL they all will be accessed through our intranet (sharepoint). I work in Ms Access and intermediate at VBA and just learing...
8
2695
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 process). Lots of decompiling and lots of compacting of the original application in A2000. Then the app was opened in A2003 and compacted,...
10
409
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 clear and I actually understand it!
0
7694
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
7609
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
7921
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
7964
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
1
5504
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
3636
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2107
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
1
1208
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
936
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

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.