Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   MCSE (http://www.velocityreviews.com/forums/f25-mcse.html)
-   -   Revolution 1309 (http://www.velocityreviews.com/forums/t582971-revolution-1309-a.html)

kpg* 01-07-2008 09:57 PM

Revolution 1309
 
Here's one for all you aspiring mcse's. Test you knowledge and
solve my problem all at the same time :).

The setup:

User has an AD network and runs a vb6 program that is installed
locally on each workstation but uses a common folder on the server
to share an access database. Point here is that the program
is not a client-server program.

Users server dies. User calls tech guy, he replaces sever
with a shiny new 2003 standard server. Tech guy somehow
restores everything and things are back to normal.

The problem:

User runs vb6 app from workstations and gets no less than
63 errors like:

Microsoft Access 2000 SR-1 Runtime
Error 1309. Error reading from file: C:\Program Files\Microsoft
Office\ART\Pfiles\MSOffice\Office\MSO7FTP.EXE
Cancel|Retry|Ignore

This is repeated with a different file 63 times. If the user
cancels it goes away after three times.

Then a message says:

Wait while Runtime Configures.

The vb6 app then runs normally after all this.

The kicker:

The user and tech guy swear on a stack of mcse training
material that the workstations were not touched, only the
sever was replaced.

What I know:

That 2003 comes out-the-box locked down pretty tight.

That the 1309 error seems to be a Microsoft Installer error and
is no doubt (in my mind) related to that stupid (in my mind)
just in time installation stuff. So the vb6 program touches
an access databse, windows things components are missing, yadda,
yadda.


What I don't know:

How, why, where the AD was restored, if from backup or from scratch.

How our vb6 app was put back on the server, by backup or install.

How competent the tech guy is.

Anyone that wants to appear really smart please clue me in.

kpg



.rev [askthemct.com] 01-08-2008 03:49 AM

Re: Revolution 1309
 
Compact and Repair on the database and make sure you can link to it, but the
error without Debug data with what line of code is throwing the error its
hard to determine,

You might also try to reinstall access on one of the systems...

I'll dig for more.

--
..rev

www.askthemct.com
..
"kpg*" <no@spam.com> wrote in message
news:Xns9A1EA24A4C647ipostthereforeiam@207.46.248. 16...
> Here's one for all you aspiring mcse's. Test you knowledge and
> solve my problem all at the same time :).
>
> The setup:
>
> User has an AD network and runs a vb6 program that is installed
> locally on each workstation but uses a common folder on the server
> to share an access database. Point here is that the program
> is not a client-server program.
>
> Users server dies. User calls tech guy, he replaces sever
> with a shiny new 2003 standard server. Tech guy somehow
> restores everything and things are back to normal.
>
> The problem:
>
> User runs vb6 app from workstations and gets no less than
> 63 errors like:
>
> Microsoft Access 2000 SR-1 Runtime
> Error 1309. Error reading from file: C:\Program Files\Microsoft
> Office\ART\Pfiles\MSOffice\Office\MSO7FTP.EXE
> Cancel|Retry|Ignore
>
> This is repeated with a different file 63 times. If the user
> cancels it goes away after three times.
>
> Then a message says:
>
> Wait while Runtime Configures.
>
> The vb6 app then runs normally after all this.
>
> The kicker:
>
> The user and tech guy swear on a stack of mcse training
> material that the workstations were not touched, only the
> sever was replaced.
>
> What I know:
>
> That 2003 comes out-the-box locked down pretty tight.
>
> That the 1309 error seems to be a Microsoft Installer error and
> is no doubt (in my mind) related to that stupid (in my mind)
> just in time installation stuff. So the vb6 program touches
> an access databse, windows things components are missing, yadda,
> yadda.
>
>
> What I don't know:
>
> How, why, where the AD was restored, if from backup or from scratch.
>
> How our vb6 app was put back on the server, by backup or install.
>
> How competent the tech guy is.
>
> Anyone that wants to appear really smart please clue me in.
>
> kpg
>
>



kpg* 01-08-2008 02:13 PM

Re: Revolution 1309
 
".rev [askthemct.com]" <ireportbadpeople@gmail.com> wrote in
news:u6BtBmaUIHA.4740@TK2MSFTNGP02.phx.gbl:

> Compact and Repair on the database and make sure you can link to it,
> but the error without Debug data with what line of code is throwing
> the error its hard to determine,
>
> You might also try to reinstall access on one of the systems...
>
> I'll dig for more.


Thanks for the reply.

hmmm, yeah...OK....compact & repair the db. worth a shot.

The program can link to the db though, as it runs normally
once the messages clear up. Also, if the program has trouble
opening the db it prompts the user if they want to run a
compact and repair. User did not indicate this happened, so
I assume the program thinks it can open the db just fine, and
in fact it does - because it runs normally.

If this were a NTFS or user permission issue the program would
not run normally.

The user indicated they don't have access or office installed
on the local machines - of this I have my doubts, but we do
not require it - we ship all components needed to open the db
as part of our install.

I instructed the tech guy to create an admin account, login
at the w/s under that account and see what happens. Next I
told him to reinstall the db components (we use jet). Next I
suggested that he copy the db to the local machine and log off
the domain and see what happens - He has not yet replied.

A goggle search for error 1309 yields results dealing with
ms project and the order of installation - this makes sense,
what does not make sense to me is why the workstations are
acting different just because the share where the db is located
has changed - no server components should be involved at all,
the share could just as well be on one of the other w/s.

Of course I'm dealing with a tech guy that is most likely in
CYA mode, so I don't know that I'm getting all the facts.


Hey, how 'bout them Tigers?

kpg

Bill Hileman 01-08-2008 02:44 PM

Re: Revolution 1309
 
"kpg*" <no@spam.com> wrote in message
news:Xns9A1F53A4589AFipostthereforeiam@207.46.248. 16...
>
> Hey, how 'bout them Tigers?


Y'all didn't beat down the buckeyes as bad as the Gators did last year.

And the Gators gave y'all a much better game.

Freakin' 5 for 5 on fourth downs. Les is insane.

We'll kick yore arse next year.



kpg* 01-08-2008 03:47 PM

Re: Revolution 1309
 
"Bill Hileman" <discgolfdad@gEEmail.com> wrote in news:#zYDITgUIHA.4476
@TK2MSFTNGP06.phx.gbl:

> "kpg*" <no@spam.com> wrote in message
> news:Xns9A1F53A4589AFipostthereforeiam@207.46.248. 16...
>>
>> Hey, how 'bout them Tigers?

>
> Y'all didn't beat down the buckeyes as bad as the Gators did last year.
>
> And the Gators gave y'all a much better game.
>
> Freakin' 5 for 5 on fourth downs. Les is insane.
>
> We'll kick yore arse next year.


Ya know, we cajuns eat dem dare gators for breakfast.

Tastes like chicken.


.rev [askthemct.com] 01-08-2008 05:52 PM

Re: Revolution 1309
 
Two more things..

1 - Is Acces in installed? (Even if it isn't required)
2 - If it is installed have updates been applied or is it a different
version?

In otherwords...Did someone install Access 2003 (for example) or an Access
2000 Service Pack on the client system then/or convert the access datavase
to the newer version?

Stuff like that breaks apps all the time, and it may only appear to be
working properly...You have an error, even if it "comes up and works after"
you need to see where the error is coming from and resolve it.

--
..rev

www.askthemct.com
..
"kpg*" <no@spam.com> wrote in message
news:Xns9A1F53A4589AFipostthereforeiam@207.46.248. 16...
> ".rev [askthemct.com]" <ireportbadpeople@gmail.com> wrote in
> news:u6BtBmaUIHA.4740@TK2MSFTNGP02.phx.gbl:
>
>> Compact and Repair on the database and make sure you can link to it,
>> but the error without Debug data with what line of code is throwing
>> the error its hard to determine,
>>
>> You might also try to reinstall access on one of the systems...
>>
>> I'll dig for more.

>
> Thanks for the reply.
>
> hmmm, yeah...OK....compact & repair the db. worth a shot.
>
> The program can link to the db though, as it runs normally
> once the messages clear up. Also, if the program has trouble
> opening the db it prompts the user if they want to run a
> compact and repair. User did not indicate this happened, so
> I assume the program thinks it can open the db just fine, and
> in fact it does - because it runs normally.
>
> If this were a NTFS or user permission issue the program would
> not run normally.
>
> The user indicated they don't have access or office installed
> on the local machines - of this I have my doubts, but we do
> not require it - we ship all components needed to open the db
> as part of our install.
>
> I instructed the tech guy to create an admin account, login
> at the w/s under that account and see what happens. Next I
> told him to reinstall the db components (we use jet). Next I
> suggested that he copy the db to the local machine and log off
> the domain and see what happens - He has not yet replied.
>
> A goggle search for error 1309 yields results dealing with
> ms project and the order of installation - this makes sense,
> what does not make sense to me is why the workstations are
> acting different just because the share where the db is located
> has changed - no server components should be involved at all,
> the share could just as well be on one of the other w/s.
>
> Of course I'm dealing with a tech guy that is most likely in
> CYA mode, so I don't know that I'm getting all the facts.
>
>
> Hey, how 'bout them Tigers?
>
> kpg



Lawrence Garvin 01-09-2008 02:35 AM

Re: Revolution 1309
 
"kpg*" <no@spam.com> wrote in message
news:Xns9A1EA24A4C647ipostthereforeiam@207.46.248. 16...
> Here's one for all you aspiring mcse's. Test you knowledge and
> solve my problem all at the same time :).
>
> The setup:
>
> User has an AD network and runs a vb6 program that is installed
> locally on each workstation but uses a common folder on the server
> to share an access database. Point here is that the program
> is not a client-server program.
>
> Users server dies. User calls tech guy, he replaces sever
> with a shiny new 2003 standard server. Tech guy somehow
> restores everything and things are back to normal.
>
> The problem:
>
> User runs vb6 app from workstations and gets no less than
> 63 errors like:
>
> Microsoft Access 2000 SR-1 Runtime
> Error 1309. Error reading from file: C:\Program Files\Microsoft
> Office\ART\Pfiles\MSOffice\Office\MSO7FTP.EXE
> Cancel|Retry|Ignore
>
> This is repeated with a different file 63 times. If the user
> cancels it goes away after three times.



How is the VB6 app authenticating with the file share on the server to
access the shared Access files?

It is simply using the context of the logged on user at the workstation? If
so, were the ACLs set correctly on the new server?

If the VB6 app is using a hardcoded account/password.. was it a local
account or a domain account?

If a local account... was the local account recreated, and were the ACLs
set correctly?

If a domain account... was the domain account rejoined to any
appropriate local groups, and were the ACLs set correctly?


> That 2003 comes out-the-box locked down pretty tight.


Yeah.... and modifying the *share* permissions would also be a strongly
recommended step, since, by default, Windows Server 2003 provides EVERYONE
"Read Only" share writes and NOBODY any write permissions, which will quite
quickly annoy the heck out of an ADO-based VB6 application if it can't open
the database RW.


> What I don't know:
>
> How, why, where the AD was restored, if from backup or from scratch.


WAS AD restored??? Was the server that died the *only* server, and the only
Domain Controller?


> How our vb6 app was put back on the server, by backup or install.


And.. what, if any, portions of the VB6 app reside on the server? Or is the
VB6 code totally client-resident, and merely executing a file access to the
network share. Also, did the VB6 app use any COM capabilities on the server
that might not have been reinstalled/restored?


> How competent the tech guy is.
>
> Anyone that wants to appear really smart please clue me in.


I'm trying to appear 'really smart' but to be honest I'm just throwin' mud
and hopin' some of it sticks to the wall.



--
Lawrence Garvin, M.S., MCBMSP, MCTS, MCP
Senior Data Architect, APQC, Houston, Texas
Microsoft MVP - Software Distribution (2005-2008)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin


Lawrence Garvin 01-09-2008 02:43 AM

Re: Revolution 1309
 
"kpg*" <no@spam.com> wrote in message
news:Xns9A1F53A4589AFipostthereforeiam@207.46.248. 16...

> If this were a NTFS or user permission issue the program would
> not run normally.


Not necessarily.... unless "run normally" includes successfully modifying
data in the database.

Still it could be permissions issues on resources other than the Access MDB
file.


> The user indicated they don't have access or office installed
> on the local machines - of this I have my doubts, but we do
> not require it - we ship all components needed to open the db
> as part of our install.


This is likely true. Since the client app is wholly contained within a VB6
app, and all data access is (likely) being performed via ADO (or maybe
something more primitive -- God help us all if that's the case), there would
be no need to have Access installed anywhere (except, maybe, the server, if
the server has been used to run Access as a database maintenance tool).

btw.... recall your original error:

>>>>Microsoft Access 2000 SR-1 Runtime<<<<


So the Access *runtime* is installed on the desktops.

But, even then, the Access *runtime* would only be required if Access/VBA
CODE embedded in the MDB datafile were needed to execute on the client
system context; otherwise, I would have thought all data access requirements
would have been addressed within the VB6 environment.

Disclaimer: While I have developed Access 2000/2002 wVBA applications using
ADO and the Access RT environment, I'm not a VB6 programmer, so what I'm
saying about VB6, per se, just might be somewhat off-the-wall and should be
taken with the appropriate rock of salt.


> Hey, how 'bout them Tigers?


Wasn't that an incredible surprise! I grew up in the shadow of Ohio State,
but I've been in Texas for almost 30 years now. I was pulling for LSU this
time, and I'm so happy to see LSU get that title -- and, to be honest, from
somebody as established as Ohio State just makes it all that much sweeter.


--
Lawrence Garvin, M.S., MCBMSP, MCTS, MCP
Senior Data Architect, APQC, Houston, Texas
Microsoft MVP - Software Distribution (2005-2008)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin


kpg* 01-09-2008 01:55 PM

Re: Revolution 1309
 
>> Anyone that wants to appear really smart please clue me in.
>
> I'm trying to appear 'really smart' but to be honest I'm just throwin'
> mud and hopin' some of it sticks to the wall.



That's all I was hoping for. :P

I'll followup once we get this resolved.

Thanks.

CBIC 01-09-2008 02:21 PM

Re: Revolution 1309
 

"kpg*" <no@spam.com> wrote in message
news:Xns9A2050A0FAE3Fipostthereforeiam@207.46.248. 16...
>>> Anyone that wants to appear really smart please clue me in.

>>
>> I'm trying to appear 'really smart' but to be honest I'm just throwin'
>> mud and hopin' some of it sticks to the wall.

>
>
> That's all I was hoping for. :P
>
> I'll followup once we get this resolved.
>
> Thanks.


The solution is very simple. Just load ESX on your new server and then move
the vm of the server over to it from your SAN.

What's that? You say you're not running VMware...oh nevermind. Good luck.




All times are GMT. The time now is 02:57 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.