{Spam?} Re: Identifying who has a record locked on Windows network

[Brian K. White]

----- Original Message ----- 
From: "Don Coleman" <dcoleman at dgcreact.com>
To: <filepro-list at lists.celestial.com>
Sent: Wednesday, July 25, 2007 11:06 AM
Subject: RE: {Spam?} Re: Identifying who has a record locked on Windows 
network


>
>> -----Original Message-----
>> From: Kenneth Brody [mailto:kenbrody at bestweb.net]
>> Sent: Wednesday, July 25, 2007 10:44 AM
>> To: Don Coleman
>> Cc: filepro-list at lists.celestial.com
>> Subject: {Spam?} Re: Identifying who has a record locked on Windows
>> network
>>
>> Quoting Don Coleman (Wed, 25 Jul 2007 10:03:46 -0400):
>>
>> > List:
>> >
>> > I probably already know the answer to this but I'll ask anyway.
>> > On a Windows network (WIN2000 Advanced Server, Windows 2000 & WINXP 
>> > Pro.
>> > Clients, fP v5.0.13 64 user license), is there anyway, within the
>> > Windows tools or using an external utility, to identify which user or
>> > work station (I'd take either) has a particular fP record locked in a
>> > file?
>> [...]
>>
>> I have looked, and I have yet to find any documented way to get this
>> information on Windows.
>>
>> --
>> KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
>> http://www.hvcomputer.com
>> http://www.fileProPlus.com
>
>
> Ken:
>
> Thank you,

This is not a fatuous comment but a real one,
Why don't you make a small investment in time, possibly a small consult fee 
to someone, to just have someone look over your app and guesstimate how 
plausible it would be to switch it to linux?

Most code actually just runs without much fuss at all, some things might 
cause migration pains but not if the unix guy is good. A lot of common 
difficulties are perfectly avoidable merely by taking some care and thought 
up front about choosing which of the 10 ways to do something.

It may sound silly to propose such a major change, but, if this is a large 
site I can only say I don't think I've ever seen a locked record on sco 
unix, or linux or freebsd that wasn't immediately identifieable, 
explainable, and able to be dealt with both not only immediately but 
gracefully. I don't think I've ever had to reboot a nix box to clear a 
record, not once. I have, on rare occasions for other things but not for 
that. filePro is just plain extremely well behaved and sane on unix.

I don't put this out there lightly or frivolously. I think it would be no 
great investment to get an initial evaluation done by one of us who 
routinely handles both platforms and periodically ports our own code back & 
forth or writes code that will work on both platforms without porting. But I 
also know it would be a serious investment in several coins to actually go 
through with it.

I'm sayng that it would be worth it. These mysterious locked records when no 
person, machine, or net connection anywhere seems to have done anything 
wrong, mysterious corrupted indexes, clerk & report binaries that just crash 
out of the blue once in a while, .. all stuff I've seen on windows too even 
on very small and lightly loaded networks with spotless hardware and os 
installs and network topology... even on single user!, and never seen on 
*nix even on the largest most heavily hammered sites except very rarely and 
it was always resolved and the cause determined, which most importantly, 
means I never had to suffer that particulr error again. No crossed fingers 
and hoping it runs ok today. So far, every time I've seen clerk or report 
actually crash, I was able to track it down almost immediately to a 
programming error on my/our part, or bad data/corrupt file. And those times, 
the file didn't just go corrupt out of the blue or for no reason. There was 
always some plain simple hardware or sys admin failure. Even on the heaviest 
used, largest boxes, there is no such thing as cron jobs to rebuild indexes 
or freechain. If I have to rebuild an index it's a big deal. If I don't 
already know why an index went bad like it wasn't because of a botched file 
transfer or crashed process or hardware, then it's an extremely big deal. As 
far as I'm concerned, putting up with stuff like that is just inconceivable. 
It's not sane. You need to work in an environment where the various rules 
are like natural laws of physics. Not in an environment where 3 random times 
a day gravity the sun doesn't work.

Suffering the occasional error is unavoidable I think, but at least if the 
environment is robust, and every error can be tracked down and _avoided_, 
instead of lived with and worked around, at least that's a sane way to 
operate and you can move steadily ahead and leave only closed holes behind 
you and after a little while all the pitfalls in your app are uncovered and 
sealed and then you can really count on your system and debug your code in a 
more sane manner because if it acts funny, you can rest assured it is the 
code that needs attention not some mysterious windows gremlin. Conversely, 
on windows, perfectly correct code may fail, leaving you with no option but 
to modify it to be basically incorrect code that happens to be the only way 
to brute force it past some inexplicable windows behaviour. Like the way 
people issue sleeps after writing and closing files before allowing the next 
process to open it. or the way one of my co-workers just "doesn't beleive" 
that umask actually works and insists on writing lots of unnecessary chmod 
commands. You are supposed to be able to rely on the os actually fulfilling 
it's advertised features. It's not a luxury it's a bare minimum base line 
starting point. Anything less is not  "mostly works, tolerable, can live 
with it, etc..." no, it's flatly not acceptable. You should not work around 
stuff like that. You should be using your brains to write more and better 
application code, not wasting 15% or more of your precious few available 
man-hours working around and recovering from having your OS fail out from 
underneath you.

It might not be as bad as you think to port over to unix either. We have a 
fairly large app and once in a great while, almost never these days since we 
stopped actively supporting windows, it takes one of us about 5 or 6 hours 
to do a conversion from nix to win or from win to nix. Granted that's our 
own code and the guy doing it has done it countless times and over the years 
a lot of code has been massaged so that it works on either platform without 
modification, so that's an optimal figure you probably will not be lucky 
enough to attain. But, it does tell you the scale your are looking at. It's 
probably on the order of days or maybe even hours to get an initial port 
that works well enough that subsequent issues can be dealt with as they turn 
up. It depends how much fancy system command stuff you do and how much 
windows-specific syntax is in the F5 menu batch files. A lot of that often 
turns out to be unecessary and is easy to deal with by just removing it. 
Like it's not necessary to specify the full path with drive letter to an fp 
binary. such a command would only work on one platform or the other, but 
just strip away the path and leave the command, and voila, now it works on 
both.

I say all this simply becasue it's frustrating to see someone struggling 
with something when you know it's unnecessary. We (by we I mean any 
unix/linux fp user I've even met, customer or developer) simply never have 
this kind of grief. A few people do have problems but, since I have had and 
eliminated the same problems myself, I'm confident that it's avoidable, and 
therefore not actually a problem at all, in their case too, merely they 
haven't done the necessary methodical debugging process and I can't do it 
for them since I have my own life to live.

The closest thing to an honest to goodness, mysterious filepro problem that 
I ever see on any *ix platform, that hasn't been explained and eliminated, 
is one that as far as anyone can tell, is doing no harm! For years and years 
and years on many boxes and several versions of 3 different os's etc... That 
issue is the way certain processes provoke DKNF warning messages without any 
explicable code or data justification. I say warning messages, not errors, 
because I have far more evidence that the message is the only thing thats 
wrong than I have that there is actually any data or processing error. And 
it's only certain few know processes that do it so even that is almost not a 
mystery since it doesn't happen at random, doesn't interfere with work, and 
doesn't have any real world consequences we've been able to detect, and is 
even able to be ignored/hidden via an fp variable now. I know what Ken says 
about this, and it sounds like the ultimate in stupidity to contradict him 
on something like that, but, it's been too many years and too much data, and 
too many transactions and too many end of months and end of years, and too 
many installations and too many varying usage patterns and too many checks 
and reports printed and too many accountant reconciliations... etc etc etc 
for there to have been an actual problem and us not have felt it somewhere.

I am _not_ one of those guys who thinks "format and istall linux" is the 
answer to all questions. That kind of ignorant statement bugs the crap out 
of me like you wouldn't beleive. Thats what I meant by this being a sincere 
not a fatuous post. It is sincere. If you have large sites that can't suffer 
unexpected crap like that, I really think you should suck it up and 
investigate the linux angle and dig in to the learning curve. Or possibly 
freebsd. At this point even I, mr. proud to love xenix, can not in good 
conscience recommend any sco product any more. Of the other unix-alikes 
linux will be _far_ and away the easiest to maintain and find reasonably 
qualified support for and the most effortless hardware compatibility too so 
thats the only reason I say linux.

I know it doesn't help you in the short term, but, every hour you spend 
beating yiur head against the wall wondering why windows isn't doing what 
it's supposed to, that very same hour could have been spent productively 
adding to your linux-fu and bringing you closer to the hour when you no 
longer have to suffer that problem ever again. Think of that goal of "no 
more mystery". If it were me I'd, starting this minute, spend every hour all 
night and all weekend from now until I knew all the in's & outs of 
installing a linux box and running fp on it and accessing that fp via 
terminal emulators. 3 non-trivial core knowledge sets that you need to be 
familiar with and which differ completely from how it all works on windows, 
but, only 3. You can get the basics of each in less time than you probably 
think even if you never looked at a unix box before in your life. especially 
if you go in that order. Just install linux, maybe several times, maybe 
several versions, first and figure out about kernel modules and hard drives 
and filesystems and backups and networking etc.. and don't even think about 
fp at all. fp would be a counter productive distraction at that point. 
forget how to spell "fp". Then move to installing fp, after you are so comfy 
installing things in general, that you can sensibly uh, make sense of fp's 
quirks, because it is quirky and not like most apps (just like it is on 
windows come to think of it). These days it's way easier to get into 
linux/bsd than it used to be to get into *nix. Cash in on that.

Another thing you'll be cashing in on is a better class of help both paid 
and free.
Those of us who use *nix have determined, at least to our own satisfaction, 
that it's a bad investment to spend any time at all trying to make things 
work reliably on windows. Mostly things work ok, and that's fine, but 
sometimes it doesn't and often there is no way to fix it because nothing is 
wrong, you don't have anything misconfigured or have bad hardware etc, you 
can't make it any more correct, and yet it fails X percent of the time. Once 
you establish that, you just write off that platform as unuseable. Or at 
least I do and a fair chunk of the people I know. So, whenever someone has a 
problem, if it's in unix there is both a lot more people with deep insight 
into the system, and a lot more of those people will be willing to take time 
to answer a question or help debug a problem methodically. In windows, there 
are actually a lot more users, but hardly any with what I'd call deep 
insight. How can there be? Probably not even very many of MS's own staff has 
deep insight into the system. The rest of us don't even have the code or 
complete or clear documentation. A lot of problems can actually be debugged 
somewhat by having basic insight into computers in general, but not many of 
the folks who have that good methodical sense are willing to squander their 
time "polishing a turd". So you really do yourself a favor lots of different 
ways at once by moving onto a *nix like os. You may not quite belive it or 
understand the motivations, but basically it's like this, to some extent at 
least, merely because it's _possible_ in unix to give you clear explicit 
directions that have known expected results and known possible causes for 
any other results, that fact alone causes some, many even, knowledgeable 
people to be willing to give you not merely general tips and pointers and 
clues, forget guesses, but actual explicit directions that you can just 
follow like a recipe. It often takes far less time for a knowledgeable admin 
to write out a few lines of arcane looking shell commands than it would for 
them to explain the dozen factors each single line takes into account. So 
they just write the lines and all you have to do is play keyboard monkey. If 
you're nervous wait a day for other people to nit-pick whatever post you are 
thinking of follwing because there is never a shortage of those. (Kind of 
like here) It's because in unix such instructions are never a waste of time. 
whether it works or not, it always moves you forward towards the answer. If 
I say "type this..." and you say you did and nothing happened, well 
depending on what that command was, I know exactly whats the next thing to 
investigate from there. No mysteries. It's almost as good as not having a 
problem when practically every problem is very straightforward to diagnose 
and always progresses very predictably and methodically from symptom, to 
some number of debugging steps that each eliminates a set of possibilities, 
to solution.

I can't tell you how priceless that ongoing peace of mind is that this 
produces. I go home or away and am just plain not worried. The process of 
diagnosing is just so straightforward. You don't feel any stress because you 
always know exactly what to do because the system is transparent. All parts 
are knowable. And "knowable" is all that matters. You don't have to actually 
know all that much yourself, you just have to know how to read docs and 
interpret error & log messages and if you have access to google at the time 
that just makes it almost effortless.

Wow I completely did not intend to get that deep into that.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!