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 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
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
"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
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
"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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
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...
|
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...
|
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...
|
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...
|
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...
| |
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...
|
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...
|
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,...
|
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!
|
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...
|
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...
| |
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. ...
|
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...
|
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...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
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
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
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...
| |