 | |
Migrating away from MS-Access
comp.databases.ms-access comp.databases.ms-access
 |
| | Thread Tools | Display Modes |
#61
 
| |||
| |||
|
Re: Migrating away from MS-Access -
10-29-2007
, 01:50 AM
|
"NewsGuy" <john (AT) nospam (DOT) com.au> wrote in news:fg1hj802cks (AT) news1 (DOT) newsguy.com: "David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote in message news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2 (AT) 216 (DOT) 196.97.142... "NewsGuy" <john (AT) nospam (DOT) com.au> wrote in news:ffur8h02d1v (AT) news4 (DOT) newsguy.com: It'd be nice if micrsoft made access into a full on development environment with easier methods of deployment...I guess they dont really want that though, they want people to go to dotnet.. What problems do you have with Access deployment? Well I dont have any really, and I have never done it, but a long time ago I researched it and only ever read bad things, my brother did it once and I believe he had nothin but trouble... I suggest that you do some investigation before making recommendations on the basis of your hazy emotions about Access deployment. At current for this project it would be unnecessary to deploy it... I was discussing with the old guy today, he said that PDF's via terminal services are chugging things up (We have alot of PDF's attached)....weather thats a reason for deployment I dont know...Im unsure if downloading the PDF would be quicker than going term services...apparently users like to click the scrolls up and down alot, and that chugs it.....i know thats been discussed earlier in this thread, all I can go on is his word at this stage... My feeling is he is probably right...so I might have to look at deployment...I am unsure.... I really don't see that this has anything at all to do with Access deployment, since it's an outside issue entirely. |
through a VPN, with sometimes poor/unreliable connections...I guess JET wont
handle that but I suppose itd be feasable with SQL Server?
John
#62
| |||
| |||
|
|
"David W. Fenton" <XXXuse... (AT) dfenton (DOT) com.invalid> wrote in messagenews:Xns99D790D8E32A4f99a49ed1d0c49c5bbb2 (AT) 216 (DOT) 196.97.142... "NewsGuy" <j... (AT) nospam (DOT) com.au> wrote in news:fg1hj802cks (AT) news1 (DOT) newsguy.com: "David W. Fenton" <XXXuse... (AT) dfenton (DOT) com.invalid> wrote in message news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2 (AT) 216 (DOT) 196.97.142... "NewsGuy" <j... (AT) nospam (DOT) com.au> wrote in news:ffur8h02d1v (AT) news4 (DOT) newsguy.com: It'd be nice if micrsoft made access into a full on development environment with easier methods of deployment...I guess they dont really want that though, they want people to go to dotnet.. What problems do you have with Access deployment? Well I dont have any really, and I have never done it, but a long time ago I researched it and only ever read bad things, my brother did it once and I believe he had nothin but trouble... I suggest that you do some investigation before making recommendations on the basis of your hazy emotions about Access deployment. At current for this project it would be unnecessary to deploy it... I was discussing with the old guy today, he said that PDF's via terminal services are chugging things up (We have alot of PDF's attached)....weather thats a reason for deployment I dont know...Im unsure if downloading the PDF would be quicker than going term services...apparently users like to click the scrolls up and down alot, and that chugs it.....i know thats been discussed earlier in this thread, all I can go on is his word at this stage... My feeling is he is probably right...so I might have to look at deployment...I am unsure.... I really don't see that this has anything at all to do with Access deployment, since it's an outside issue entirely. Well as soon as we deploy it outside of terminal services we'd be running through a VPN, with sometimes poor/unreliable connections...I guess JET wont handle that but I suppose itd be feasable with SQL Server? John |
Linux boxes.
Advantages?
To you:
A completely fresh start with technologies about which you are more
knowledgeable.
To me:
This thread is transferred to another newsgroup.
No more "old guy" pejoratives.
#63
| |||
| |||
|
|
On Oct 29, 3:50 am, "NewsGuy" <j... (AT) nospam (DOT) com.au> wrote: "David W. Fenton" <XXXuse... (AT) dfenton (DOT) com.invalid> wrote in messagenews:Xns99D790D8E32A4f99a49ed1d0c49c5bbb2 (AT) 216 (DOT) 196.97.142... "NewsGuy" <j... (AT) nospam (DOT) com.au> wrote in news:fg1hj802cks (AT) news1 (DOT) newsguy.com: "David W. Fenton" <XXXuse... (AT) dfenton (DOT) com.invalid> wrote in message news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2 (AT) 216 (DOT) 196.97.142... "NewsGuy" <j... (AT) nospam (DOT) com.au> wrote in news:ffur8h02d1v (AT) news4 (DOT) newsguy.com: It'd be nice if micrsoft made access into a full on development environment with easier methods of deployment...I guess they dont really want that though, they want people to go to dotnet.. What problems do you have with Access deployment? Well I dont have any really, and I have never done it, but a long time ago I researched it and only ever read bad things, my brother did it once and I believe he had nothin but trouble... I suggest that you do some investigation before making recommendations on the basis of your hazy emotions about Access deployment. At current for this project it would be unnecessary to deploy it... I was discussing with the old guy today, he said that PDF's via terminal services are chugging things up (We have alot of PDF's attached)....weather thats a reason for deployment I dont know...Im unsure if downloading the PDF would be quicker than going term services...apparently users like to click the scrolls up and down alot, and that chugs it.....i know thats been discussed earlier in this thread, all I can go on is his word at this stage... My feeling is he is probably right...so I might have to look at deployment...I am unsure.... I really don't see that this has anything at all to do with Access deployment, since it's an outside issue entirely. Well as soon as we deploy it outside of terminal services we'd be running through a VPN, with sometimes poor/unreliable connections...I guess JET wont handle that but I suppose itd be feasable with SQL Server? John I suggest that you convert to JDBC and SQLite with a GLOM front end on Linux boxes. Advantages? To you: A completely fresh start with technologies about which you are more knowledgeable. To me: This thread is transferred to another newsgroup. No more "old guy" pejoratives. |
I apologies for the "old guy" pejoratives, I didn't think I was doing that
too bad after the first few posts, but perhaps I am...
John
#64
| |||
| |||
|
|
"NewsGuy" <john (AT) nospam (DOT) com.au> wrote in news:fg43am0qdp (AT) news5 (DOT) newsguy.com: "David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote in message news:Xns99D790D8E32A4f99a49ed1d0c49c5bbb2 (AT) 216 (DOT) 196.97.142... "NewsGuy" <john (AT) nospam (DOT) com.au> wrote in news:fg1hj802cks (AT) news1 (DOT) newsguy.com: "David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote in message news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2 (AT) 216 (DOT) 196.97.142... "NewsGuy" <john (AT) nospam (DOT) com.au> wrote in news:ffur8h02d1v (AT) news4 (DOT) newsguy.com: It'd be nice if micrsoft made access into a full on development environment with easier methods of deployment...I guess they dont really want that though, they want people to go to dotnet.. What problems do you have with Access deployment? Well I dont have any really, and I have never done it, but a long time ago I researched it and only ever read bad things, my brother did it once and I believe he had nothin but trouble... I suggest that you do some investigation before making recommendations on the basis of your hazy emotions about Access deployment. At current for this project it would be unnecessary to deploy it... I was discussing with the old guy today, he said that PDF's via terminal services are chugging things up (We have alot of PDF's attached)....weather thats a reason for deployment I dont know...Im unsure if downloading the PDF would be quicker than going term services...apparently users like to click the scrolls up and down alot, and that chugs it.....i know thats been discussed earlier in this thread, all I can go on is his word at this stage... My feeling is he is probably right...so I might have to look at deployment...I am unsure.... I really don't see that this has anything at all to do with Access deployment, since it's an outside issue entirely. Well as soon as we deploy it outside of terminal services we'd be running through a VPN, with sometimes poor/unreliable connections...I guess JET wont handle that but I suppose itd be feasable with SQL Server? Yes, of course. Everyone has told you repeatedly that much of the problem with the app as you've described it would be best addressed with a more appropriate back end. Jet can't be used across a WAN, and anyone with any competence at all in Access would know that. This is not an *Access* deployment issue -- it's a matter of choosing the appropriate back end for the app and its deployment requirements. If WTS isn't working, and you're blocked from other avenues by the Jet back end, then it's pretty clear that someone made some bad design decisions somewhere along the line. But it still isn't an Access deployment issue. |
away from terminal services, and was asking if sqlserver would do ok with
access deployed...which in retrospect is a stupid question and to boot wasnt
worded very well at all...
Thanks for spending your time on me..
John
#65
| |||
| |||
|
|
Jet can't be used across a WAN, |
I'm thinking of a multi-building campus...
--
PeteCresswell
#66
| |||
| |||
|
|
Per David W. Fenton: Jet can't be used across a WAN, Where does LAN end and WAN begin? I'm thinking of a multi-building campus... -- PeteCresswell |
connection, fucked backend...
For us it wont run is the bottom line, no hope in hell.....It's regional
Australia, so we are talking large distances some with substandard
connections..
I spose Id call a WAN one that uses external communication links that arnt
under the control of internal staff...
John
#67
| |||
| |||
|
|
If I were handed a project like this, the first thing I'd do would be refactoring everything to come up to my coding standards. That means changing no functionality at all, and just converting it to be done right. That would involve steps in this order: 1. use Speed Ferret to fix all the naming problems. 2. go through the code sub/function by sub/function and fix the formatting and naming conventions. Change *no* functionality at all. 3. fix the dependencies on other forms without changing functionality. That is, just make the most minimal changes to get rid of the dependencies and do it right. Obviously, step 1 involves both the front end and back end. The point here is to do something with the code that makes it better without actually changing what it does or how it works. The process of doing this will force you to become familiar with the application as it stands now, and will then enable you to understand what needs to be redesigned/replaced. Only after a refactoring would I then embark on trying to fix the design problems. |
been "Find And Replace".
--
PeteCresswell
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.