Thanks. I'll take a look at that.

Kurt

On Tue, Feb 2, 2016 at 1:04 PM, Andrew Tallarita
<[email protected]> wrote:
> Kurt,
>
>
> We had a similar issue recently with ODBC connections being dropped/lost and
> for us it was related to a change M$ made in 7 and 8 in how in handles the
> 32 and 64 bit connections differently than from before with a ::Cough::
> "Security update". I for the life of me can't remember nor find the details
> right now.
>
> We had to use the ODBC Data Source Administrator (32-bit) and make sure that
> under the Platform column for that connection it listed it as "32/64-bit"
> and in order to do so we basically removed the existing connections,
> rebooted and reestablished the connections.  We've been fine after, although
> this is also with a connection to our SQL servers and Win 7(64-bit) clients.
>
> Hope this gives you some headway.
>
>
> Regards,
>
> Andrew Tallarita
> IT Support Specialist
> BNL Industries Inc,.
> [email protected]
> ph: 860.870.6222
> cell: 860.849.1654
> http://www.bnl.com
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
> for the sole use of the intended recipient(s) and may contain confidential
> and privileged information or otherwise be protected by law. This notice
> serves as a confidentiality marking for the purpose of any confidentiality
> or nondisclosure agreement. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, you
> should not disseminate, distribute or copy this e-mail. Please notify the
> sender immediately by e-mail, if you have received this e-mail by mistake
> and delete this e-mail from your system. E-mail transmissions cannot be
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or contain viruses. The sender,
> therefore, does not accept liability for any errors, omissions or damage
> caused by any virus transmitted by this error.
>
> Information contained herein is subject to the Code of Federal Regulations
> Chapter 22 International Traffic in Arms Regulations. This data may not be
> resold, diverted, transferred, transshipped, made available to a foreign
> national within the United States, or otherwise disposed of in any other
> country outside of its intended destination, either in original form or
> after being incorporated through an intermediate process into other data
> without the prior written approval of the US Department of State.
>
> On Tue, Feb 2, 2016 at 1:26 PM, Kurt Buff <[email protected]> wrote:
>>
>> All,
>>
>> We have three machines in our shipping department running UPS Worldship.
>>
>> There used to be only one workstation, and it was wired, but we
>> reworked the shipping area, and now there are three workstations in an
>> area that's never been wired, so all three stations are wireless - I
>> don't know if this is relevant or not, but it probably is.
>>
>> The program gets data from our ancient ERP system - it generates text
>> files that it places on a share - via an ODBC connection that's mapped
>> to that share for those text files.
>>
>> What's happening is that frequently (more than once a week) the Win8.1
>> workstation is losing its ODBC connection (it also happens, but much
>> less often, to the Win7 machines). The Explorer drive mapping remains,
>> or is remapped, I'm not sure which - we're using a GPP for the drive
>> mapping.
>>
>> Once this happens, I must use odbcad32.exe to remap the drive, because
>> even though it's already mapped in Explorer, the drive letter doesn't
>> show for ODBC.
>>
>> So far, it only seems to happen if the user logs off or shuts down the
>> machine overnight - never during the day after they've logged in. I've
>> checked the power settings for the workstations, and they're set as I
>> would expect - no sleeping, hibernating, etc.
>>
>> I'm not finding anything in the workstation event logs that seems
>> relevant.
>>
>> I'm running a trial now, asking them to just lock the workstations at
>> night, to see if that helps, but has anyone run into this kind of
>> problem, or have thoughts on how to mitigate it?
>>
>>
>> Thanks,
>>
>> Kurt
>>
>>
>


Reply via email to