Albert thanks for wading through all this.
"Albert D. Kallal" <kallal@msn.com> wrote in message news:<vqc_d.708057$6l.440252@pd7tw2no>...[color=blue]
> Gee, you should at least try and break up the number of questions,a nd
> issues into separate posts here.[/color]
Yep. Will do. Sorry.
[color=blue]
> The first thing I would look at is the performance issue of:
>[color=green]
> > meanwhile the JET based version, running under terminal server, has
> > suddenly started running very slowly.[/color]
> Gee, "suddenly" started running slowly. ... So, you are telling me that
> NOTHING was changed on the server? .....[/color]
The network has had lots of maintenance on it, new servers and system
software upgraded, around the time the slowness was noticed. I can't
obtain from them anything more substantial than that. There is no
doubt that the environment changed.
[color=blue]
> I would perhaps try using a persistent connection from the FE (front end)
> database, to the back end database.[/color]
(and, I assume you are competent here,
Yes. There is a "de facto" persistent connection by way of a "home
form" which is based on a recordset of Orders. However occasionally a
user will close this screen to run another function. I'll open a ...
global defined rs in autoexec and leave it open for the whole session,
right?
[color=blue]
> and of course always give each user a separate copy (preferably a mde).[/color]
Yes. That is being done, and in TS too. I have an auto front end
updater similar to one I saw somewhere.
[color=blue][color=green]
> > The network engineer has thrown
> > up his hands and said "It's Access 97". I've checked out lots of
> > things including the Oplocks setting and other stuff from this NG, and
> > I think I've done everything right. Since the App performs fine
> > outside of TS I challenged the network guy on this, asking him where
> > he got the idea it was A97.[/color]
>
> In fact, while users are working on the application, walk up to the server,
> logon as a user, and now try the application. In this example, there is NO
> terminal services running here! And, I will bet a million dollars, the
> application will STILL RUN slow. (the reason for this is that terminal
> services is
> simply a remote desktop connection to the server!!...the fact of TS, or the
> remote desktop connection is going to have ZERO influence on the performance
> issue here!). So, walk to the server room, long on, and run the application.
> (make sure other users are working, and USING the application (via TS)
> when you do this
> test). Like I say, you can guarantee that the application will run the same
> (ie: slow for you).[/color]
Thanks, will try this.
[color=blue][color=green]
> >I challenged the network guy on this, asking him where
> > he got the idea it was A97.[/color]
>
> Well, he is a network guy, and can't possibility know what ANY COMPETENT
> ms-access developer will know!![/color]
I don't mind him being incompetent when it comes to ms-access, it's
advising the client to get rid of Access 97 and rewriting everything
in .Net that pressed my button. And then trying to justify his
arguments by quoting someone's blog.
That 'BASIC' competency I am talking about[color=blue]
> is
> that you must give each user their OWN copy of the front end, and further,
> 99% of the time, making sure your application keeps a persistent connection
> will fix the performance problems (You can Google on this issue..but it kind
> of like stating that humans breath air!). An excellent reference to check
> for
> performance, and one that outlines the persistent connection trick can be
> found here:
>
>
http://www.granite.ab.ca/access/performancefaq.htm
> Check the above, and also of course make sure you installed the updates and
> bug fixes to office97 (that is sr1, sr2b, and VERY important to install the
> jet update of jet35sp3.exe.[/color]
SR2 is OK I believe, and I'll check TS for Jet
[color=blue]
> PREFERABLY this should be a mde).[/color]
Haven't seen that before ... Yes I do know mde's ... will try after
other options. (I run /decompile occasionally, but that's not the
same?)
[color=blue]
>
>[color=green]
> >So, there will come a time in the
> > near future when these applications will no longer run on Microsoft
> > Operating Systems.[/color]
> Oh really? Ask your self the following question:
>
> are people stupid, or did Microsoft get successful because they are
> smart?
>
> It is very important to note here that Apple Computer on several occasions
> has forced developers to throw out their code.
>
> Microsoft on the other hand says we are going to work VERY hard to keep your
> old code running. What this means is that overtime a competitor to Microsoft
> forces developers and business to THROW OUT their software when a new OS
> comes also, those customers as a general rule migrated OUT of that platform,
> and into Microsoft hands. In other words, one of Microsoft secrete weapons
> for their success has been that they PRESERVE your software investment.
>
> There is nothing stopping you from writing code with ms-access version 2.0
> (what 1994??). In fact we still frequently get questions here about that
> version. There is nothing stopping you from writing software using FoxPro
> 2.0. That is also a dos based "text" system, and is also about 1992.
>
> Microsoft has the best track record in the industry in this regards. You can
> still run all that old software. You can even run most of it in windows2000,
> which really does not even has dos anymore.
>
> Apple, and good many of the other vendors out there have forced numerous
> upgrades upon their users. For example, all of the old applications for the
> old Apple Macintosh (such as Mac-paint etc). DO NOT work on the new
> platforms. In other words, just about all of the 1980' applications (and
> early 90's code) for the Apple Mac do not work anymore. They WERE FORCED to
> upgrade. ALL OF MY "dos" from the early 1980's still runs fine on the
> newest windows box. Microsoft does not have a policy of "breaking", or not
> allowing the old code to run. They have the best track record in the
> industry by far in this regard.
>
> So, really, I don't see any problem here. Nothing is stopping you from using
> the 1992 version of dos based Reflex is there? (I have some clients still
> running that)
>
> If you want, you can jump over to Dan Bricklins site, and download the
> ORIGINAL spread sheet for the ibm pc. It still works today! Do any of you
> remember VisiCalc? It is only a 27k download for a whole spread sheet!.
> Simply amazing. By the way, this spreadsheet is from the original 1981
> VisiCalc disk, and it still runs on Windows today! (heck, the average GIF on
>
>
> Just how old of code are trying to run here? We can't go back before 1981,
> since the Pc did not exist. Hence, I can't help you with code before that.
> On the other hand, there are good number of Atari, and Apple II sites with
> great emulators that let you that lots of code from the 1970's.
>
> So, if you want to run some software that is MORE THEN 20 years old, then
> Go to dan's site, and download the ORIGINAL spreadsheet for the pc!!
> Here is the link:
>
http://www.bricklin.com/visicalc.htm
>
> By the way, that spreadsheet still runs on a brand new windows xp box.
>
> Anyone who does not realize the INCREASABLE track record of Microsoft, and
> the
> compatible record simply has not a clue as to why (one reason) MS got so
> successful.....and I can tell you it is not because people are stupid!!
>
> But, if you want to run access 1.0, or Visual Basic 3.0...you can...
>[color=green]
> >Access 2003 already uses the VB.NET language as the code behind Access
> > 2003.[/color]
>
> This is 100% DEAD WRONG. Ms-access continues to use VBA, and will
> so for the future.
>[color=green]
> > Access 2003 will currently run VBA code just as the first
> > version of VB.NET ran VB 6.0 code.[/color]
>
> Utter rubbish. VB.net does NOT run VB 6.0 code at all!!
>[color=green]
> > The latest version of VB.NET will
> > run "some" VB6.0 code, but not all. This is the avenue VBA will take.[/color]
>
> Sorry, just not the case. Ask your self if Microsoft is willing to torture,
> and have 400+ million uses of Excel through out all their spreadsheets, and
> start over? (remember, macros in Excel is VBA!!!). Anyone with a function
> brain will realize that VBA support will continue for a very long time
> indeed. If MS throws out Excel, and starts over, then you will have a
> situation JUST like apple computer, where each time Apple did this, they
> lost customers. I really am very sorry, but Microsoft is in fact a VERY well
> run company..and is far more intelligent that the garbage that poster
> is spooning out. Once can argue that some of the posters info is in fact
> Ms marketing stuff..but the fact remains that MS cares about preserving your
> software, and their track record BEATS the competitors by a COUNTRY MILE in
> terms of their systems sporting 5, 10 or even 20 year old software!![/color]
OK Albert that was exactly what I was looking for - I'll show that to
the client.
Some other things:
I did try one other thing - refreshing links to the backend on
startup. I used to just leave the links as is when the new front ends
were copied down. Anyway didn't make any difference.
The Oplocks setting is switched OFF.
There was one machine (not connected through TS) that we found was
corrupting the back end (incidentally by following advice from this
group about inspecting the ldb file). Got the engineer to take it
away (faulty NIC, cable, whatever) and that's OK now, but the slowness
remained.
I also set up this application on my piddly littlehome network, with
three computers - P4 2.4 W2K, P3 666 W2K, P3 450 laptop Win 98. Set
the backend up on the P4 2.4, connected all 3 to the backend and ran
one of the main functions that was taking forever at the site, at the
same time committing two Orders on the other two machines. It ran
flawlessly and quickly, which makes me think it's the environment at
the site.
There's other stuff that might prompt further comments from you Albert
but I guess the main thing I was looking for was the critique of the
blog.
Thanks very much when I get to the bottom of this I'll let you know.
Terry Bell
