Hi Team,
   Is it possible to find out what 'Failed' during a table Verification?
Regards,
Ian

Ian


Don't think so - why?

Roy Lambert

Hi Roy,

   Thought it would be handy to be able to know what failed verification.  Perhaps understand any trends or relate it to
any events.

Ian

Ian


Generally speaking failing validation means you've had a catastrophic crash, you have conflicting versions of ElevateDB installed, or conflicting settings, or Tim get it wrong. Ordinary normal operation should not give rise to a problem that will fail validation.

What its best to do if you have a problem is:

1. copy the ENTIRE database (config, catalog, and tables) sideways
2. repair the affected tables/database
3. have a look at release notes / error lists
4. if you think its a "Tim" problem that he doesn't know about let him know

Oh yeah I forgot a potential cause or two - developer screw up, user messing about, or malicious interference (ie just try hacking a table with a hex editor - fun!

Roy Lambert

Hi Roy,
   As I have mentioned elsewhere, this particular Customer has a flaky network that hiccups every now and then.
   They seem to think it is something being reflected back into their LAN when their ISP hiccups.  There is some evidence
to support this but I'm not 100% convinced.
   They were supposed to isolate their LAN entirely for a few days and see how it went but they haven't done that yet.

Regards,
Ian

Ian


Are they running f/s or c/s. If the latter change the ports to something the ISP won't (or at least shouldn't) access. Just reading again is this LAN or WAN?

Roy Lambert

Hi Roy,
   All LAN, local mode.

Ian

Ian


Then I don't see how their ISP can affect them unless it bollixing the router

Roy Lambert

"Ian Branch" wrote:

All LAN, local mode.

Don't overlook that they may be hitting the post-SMB1 file sharing issues. M$ broke reliable file sharing with SMB2 onwards. It's for that reason that we're deploying only in C/S mode with EDB.

See here: https://www.elevatesoft.com/bulletins?action=view&category=edb&bulletin=smb2_data_corruption

It's not been fixed. Essentially for performance reasons, file metadata (like how big the file is) is cached at workstations so the redirector doesn't have to ask the server how big a file is before appending a new block. This works when no other process is also updating the file.

We've had to get a number of customers to disable SMB2 onwards on their servers - forcing use of SMB1 - to avoid DBISAM table corruption in local mode. Either that or move them to C/S mode.

Charles Bainbridge wrote:

> "Ian Branch" wrote:
>
> All LAN, local mode.
>
> Don't overlook that they may be hitting the post-SMB1 file sharing issues. M$ broke reliable file sharing with SMB2
> onwards. It's for that reason that we're deploying only in C/S mode with EDB.
>
> See here: https://www.elevatesoft.com/bulletins?action=view&category=edb&bulletin=smb2_data_corruption
>
> It's not been fixed. Essentially for performance reasons, file metadata (like how big the file is) is cached at
> workstations so the redirector doesn't have to ask the server how big a file is before appending a new block. This
> works when no other process is also updating the file.
>
> We've had to get a number of customers to disable SMB2 onwards on their servers - forcing use of SMB1 - to avoid
> DBISAM table corruption in local mode. Either that or move them to C/S mode.

Hi Charles,

   That is interesting.  Do you happen to know if the SMB2 issue is still present in Windows Server 2012 R2?
   This particular customer is running the above server with Win XP & Win 7 workstations.

Regards,
Ian