Low lever record count writer  
Author Message
hjross





PostPosted: Tue Jan 30 05:01:01 CST 2007 Top

Exchange Servers >> Low lever record count writer

I need a basic table repair utility to write the correct no of recs into a
table header. Is there any free or shareware around to do this?
Thanks.
-LS

Exchange Server5  
 
 
Bob





PostPosted: Tue Jan 30 05:01:01 CST 2007 Top

Exchange Servers >> Low lever record count writer Lew

Take a look at
http://rcl-systems.blogspot.com/2006/09/visual-foxpro-corrupt-tables-due-to_26.html

It has code to resolve corrput table headers and to fix the problem by
re-writing the headers.

--
Regards

Bob B.




> I need a basic table repair utility to write the correct no of recs into a
> table header. Is there any free or shareware around to do this?
> Thanks.
> -LS
>
>
>
 
 
Lew





PostPosted: Tue Jan 30 08:40:44 CST 2007 Top

Exchange Servers >> Low lever record count writer That's kind of what I'm in the process of doing myself. I wonder if the
actual record count can't be derived more quickly from the table size, ie
(tablesize - header size)/record length. The actual record length is also
store in the header. It'd save a few steps.
-Lew


> Lew
>
> Take a look at
> http://rcl-systems.blogspot.com/2006/09/visual-foxpro-corrupt-tables-due-to_26.html
>
> It has code to resolve corrput table headers and to fix the problem by
> re-writing the headers.
>
> --
> Regards
>
> Bob B.
>
>

>
>> I need a basic table repair utility to write the correct no of recs into
>> a
>> table header. Is there any free or shareware around to do this?
>> Thanks.
>> -LS
>>
>>
>>


 
 
Bob





PostPosted: Wed Jan 31 05:34:00 CST 2007 Top

Exchange Servers >> Low lever record count writer Lew,

Provided the size value is correct - it would work.

I developed this solution for a client where the record header was not
correct due what appears to be a locking/release problem caused by Anti-V
software.
This put me in the situation of not being able to rely on info in the header
record data.

Your other post of using Append/Pack/Delete is of interest, I will test it
out (when I can find a backup of my corrupted tables).

Regards

Bob B.




> That's kind of what I'm in the process of doing myself. I wonder if the
> actual record count can't be derived more quickly from the table size, ie
> (tablesize - header size)/record length. The actual record length is also
> store in the header. It'd save a few steps.
> -Lew


> > Lew
> >
> > Take a look at
> > http://rcl-systems.blogspot.com/2006/09/visual-foxpro-corrupt-tables-due-to_26.html
> >
> > It has code to resolve corrput table headers and to fix the problem by
> > re-writing the headers.
> >
> > --
> > Regards
> >
> > Bob B.
> >
> >

> >
> >> I need a basic table repair utility to write the correct no of recs into
> >> a
> >> table header. Is there any free or shareware around to do this?
> >> Thanks.
> >> -LS
> >>
> >>
> >>
>
>
>
 
 
Lew





PostPosted: Wed Jan 31 23:09:03 CST 2007 Top

Exchange Servers >> Low lever record count writer The other post has issues when there are dbc based validations. I've just
turned off av for all my data directories. Since we don't do anything
esoteric (like putting code or macros in tables) I don't see how a data file
can be infected. 24x7 solutions are certainly harmed by av.


> Lew,
>
> Provided the size value is correct - it would work.
>
> I developed this solution for a client where the record header was not
> correct due what appears to be a locking/release problem caused by Anti-V
> software.
> This put me in the situation of not being able to rely on info in the
> header
> record data.
>
> Your other post of using Append/Pack/Delete is of interest, I will test it
> out (when I can find a backup of my corrupted tables).
>
> Regards
>
> Bob B.
>
>

>
>> That's kind of what I'm in the process of doing myself. I wonder if the
>> actual record count can't be derived more quickly from the table size, ie
>> (tablesize - header size)/record length. The actual record length is also
>> store in the header. It'd save a few steps.
>> -Lew


>> > Lew
>> >
>> > Take a look at
>> > http://rcl-systems.blogspot.com/2006/09/visual-foxpro-corrupt-tables-due-to_26.html
>> >
>> > It has code to resolve corrput table headers and to fix the problem by
>> > re-writing the headers.
>> >
>> > --
>> > Regards
>> >
>> > Bob B.
>> >
>> >

>> >
>> >> I need a basic table repair utility to write the correct no of recs
>> >> into
>> >> a
>> >> table header. Is there any free or shareware around to do this?
>> >> Thanks.
>> >> -LS
>> >>
>> >>
>> >>
>>
>>
>>


 
 
Dan





PostPosted: Thu Feb 01 00:37:24 CST 2007 Top

Exchange Servers >> Low lever record count writer ANY file-based application is harmed by over-zealous AV. Heck, one of the
most frequently posted problems in the Word newsgroups is fixed by
uninstalling the AV addin for Office. The addin adds nothing other than an
emotional crutch, and prevents Word from saving to disk when it needs to
save to disk.

Anything that interferes with disk I/O is potentially a problem for
file-based applications.

Even if you have code in tables that you execute with ExecScript(), there is
no avenue for exploits unless you allow users to put code in that table. My
execscripts are on code that I park there and don't let the application
users update.

And as dead as Xbase is, do you REALLY think any exploit is going to write
valid Xbase code for insertion (which you don't allow anyway)?

Turn off AV on your data directories. The only thing it does is slow down
performance, and quite possibly interfere with successful disk writes.
Nothing causes corruption better than disk write interference.

Dan




> The other post has issues when there are dbc based validations. I've just
> turned off av for all my data directories. Since we don't do anything
> esoteric (like putting code or macros in tables) I don't see how a data
> file can be infected. 24x7 solutions are certainly harmed by av.


>> Lew,
>>
>> Provided the size value is correct - it would work.
>>
>> I developed this solution for a client where the record header was not
>> correct due what appears to be a locking/release problem caused by Anti-V
>> software.
>> This put me in the situation of not being able to rely on info in the
>> header
>> record data.
>>
>> Your other post of using Append/Pack/Delete is of interest, I will test
>> it
>> out (when I can find a backup of my corrupted tables).
>>
>> Regards
>>
>> Bob B.
>>
>>

>>
>>> That's kind of what I'm in the process of doing myself. I wonder if the
>>> actual record count can't be derived more quickly from the table size,
>>> ie
>>> (tablesize - header size)/record length. The actual record length is
>>> also
>>> store in the header. It'd save a few steps.
>>> -Lew


>>> > Lew
>>> >
>>> > Take a look at
>>> > http://rcl-systems.blogspot.com/2006/09/visual-foxpro-corrupt-tables-due-to_26.html
>>> >
>>> > It has code to resolve corrput table headers and to fix the problem by
>>> > re-writing the headers.
>>> >
>>> > --
>>> > Regards
>>> >
>>> > Bob B.
>>> >
>>> >

>>> >
>>> >> I need a basic table repair utility to write the correct no of recs
>>> >> into
>>> >> a
>>> >> table header. Is there any free or shareware around to do this?
>>> >> Thanks.
>>> >> -LS
>>> >>
>>> >>
>>> >>
>>>
>>>
>>>
>
>


 
 
Lew





PostPosted: Thu Feb 01 10:29:54 CST 2007 Top

Exchange Servers >> Low lever record count writer ...plus it's a pain in the ass.


> ANY file-based application is harmed by over-zealous AV. Heck, one of the
> most frequently posted problems in the Word newsgroups is fixed by
> uninstalling the AV addin for Office. The addin adds nothing other than an
> emotional crutch, and prevents Word from saving to disk when it needs to
> save to disk.
>
> Anything that interferes with disk I/O is potentially a problem for
> file-based applications.
>
> Even if you have code in tables that you execute with ExecScript(), there
> is no avenue for exploits unless you allow users to put code in that
> table. My execscripts are on code that I park there and don't let the
> application users update.
>
> And as dead as Xbase is, do you REALLY think any exploit is going to write
> valid Xbase code for insertion (which you don't allow anyway)?
>
> Turn off AV on your data directories. The only thing it does is slow down
> performance, and quite possibly interfere with successful disk writes.
> Nothing causes corruption better than disk write interference.
>
> Dan
>
>


>> The other post has issues when there are dbc based validations. I've just
>> turned off av for all my data directories. Since we don't do anything
>> esoteric (like putting code or macros in tables) I don't see how a data
>> file can be infected. 24x7 solutions are certainly harmed by av.


>>> Lew,
>>>
>>> Provided the size value is correct - it would work.
>>>
>>> I developed this solution for a client where the record header was not
>>> correct due what appears to be a locking/release problem caused by
>>> Anti-V
>>> software.
>>> This put me in the situation of not being able to rely on info in the
>>> header
>>> record data.
>>>
>>> Your other post of using Append/Pack/Delete is of interest, I will test
>>> it
>>> out (when I can find a backup of my corrupted tables).
>>>
>>> Regards
>>>
>>> Bob B.
>>>
>>>

>>>
>>>> That's kind of what I'm in the process of doing myself. I wonder if the
>>>> actual record count can't be derived more quickly from the table size,
>>>> ie
>>>> (tablesize - header size)/record length. The actual record length is
>>>> also
>>>> store in the header. It'd save a few steps.
>>>> -Lew


>>>> > Lew
>>>> >
>>>> > Take a look at
>>>> > http://rcl-systems.blogspot.com/2006/09/visual-foxpro-corrupt-tables-due-to_26.html
>>>> >
>>>> > It has code to resolve corrput table headers and to fix the problem
>>>> > by
>>>> > re-writing the headers.
>>>> >
>>>> > --
>>>> > Regards
>>>> >
>>>> > Bob B.
>>>> >
>>>> >

>>>> >
>>>> >> I need a basic table repair utility to write the correct no of recs
>>>> >> into
>>>> >> a
>>>> >> table header. Is there any free or shareware around to do this?
>>>> >> Thanks.
>>>> >> -LS
>>>> >>
>>>> >>
>>>> >>
>>>>
>>>>
>>>>
>>
>>
>
>


 
 
Dan





PostPosted: Thu Feb 01 10:51:36 CST 2007 Top

Exchange Servers >> Low lever record count writer ROFL!

Yes, there's that too.

Dan



> ...plus it's a pain in the ass.


>> ANY file-based application is harmed by over-zealous AV. Heck, one of the
>> most frequently posted problems in the Word newsgroups is fixed by
>> uninstalling the AV addin for Office. The addin adds nothing other than
>> an emotional crutch, and prevents Word from saving to disk when it needs
>> to save to disk.
>>
>> Anything that interferes with disk I/O is potentially a problem for
>> file-based applications.
>>
>> Even if you have code in tables that you execute with ExecScript(), there
>> is no avenue for exploits unless you allow users to put code in that
>> table. My execscripts are on code that I park there and don't let the
>> application users update.
>>
>> And as dead as Xbase is, do you REALLY think any exploit is going to
>> write valid Xbase code for insertion (which you don't allow anyway)?
>>
>> Turn off AV on your data directories. The only thing it does is slow down
>> performance, and quite possibly interfere with successful disk writes.
>> Nothing causes corruption better than disk write interference.
>>
>> Dan
>>
>>


>>> The other post has issues when there are dbc based validations. I've
>>> just turned off av for all my data directories. Since we don't do
>>> anything esoteric (like putting code or macros in tables) I don't see
>>> how a data file can be infected. 24x7 solutions are certainly harmed by
>>> av.


>>>> Lew,
>>>>
>>>> Provided the size value is correct - it would work.
>>>>
>>>> I developed this solution for a client where the record header was not
>>>> correct due what appears to be a locking/release problem caused by
>>>> Anti-V
>>>> software.
>>>> This put me in the situation of not being able to rely on info in the
>>>> header
>>>> record data.
>>>>
>>>> Your other post of using Append/Pack/Delete is of interest, I will test
>>>> it
>>>> out (when I can find a backup of my corrupted tables).
>>>>
>>>> Regards
>>>>
>>>> Bob B.
>>>>
>>>>

>>>>
>>>>> That's kind of what I'm in the process of doing myself. I wonder if
>>>>> the
>>>>> actual record count can't be derived more quickly from the table size,
>>>>> ie
>>>>> (tablesize - header size)/record length. The actual record length is
>>>>> also
>>>>> store in the header. It'd save a few steps.
>>>>> -Lew


>>>>> > Lew
>>>>> >
>>>>> > Take a look at
>>>>> > http://rcl-systems.blogspot.com/2006/09/visual-foxpro-corrupt-tables-due-to_26.html
>>>>> >
>>>>> > It has code to resolve corrput table headers and to fix the problem
>>>>> > by
>>>>> > re-writing the headers.
>>>>> >
>>>>> > --
>>>>> > Regards
>>>>> >
>>>>> > Bob B.
>>>>> >
>>>>> >

>>>>> >
>>>>> >> I need a basic table repair utility to write the correct no of recs
>>>>> >> into
>>>>> >> a
>>>>> >> table header. Is there any free or shareware around to do this?
>>>>> >> Thanks.
>>>>> >> -LS
>>>>> >>
>>>>> >>
>>>>> >>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>
>