Crashing

[omni]

Loaded the change to dbesys. Installed in 3 locations this morning on weekly standard updates. In all 3 locations there were two files that once updated normally by user with add/update locked up, Operating system error. Tried to rebuild by bringing a blank file down and importing to it using xdot. Did not help. same issue. Anytime the file was just opened it got an eof() and then locked the entire app up.
There are the only 3 sites right now with dclip1.lib loaded and using dbesys.
Brought the files back to our office, used foxpro26 to import them and sent them back to the users site and then the inquiries functioned. Fear that if they add any records it will just do the same thing.
Two are 1.9, 1 is 2.0

********************************************************

IF ! DbeLoad( "CDXDBE",.T.)
Alert( "Database-Engine CDXDBE not loaded" , {"OK"} )
ENDIF

IF ! DbeLoad( "FOXDBE",.T.)
Alert( "Database-Engine FOXDBE not loaded" , {"OK"} )
ENDIF

IF ! DbeBuild( "FOXCDX", "FOXDBE", "CDXDBE" )
Alert( "FOXCDX Database-Engine;Could not build engine" , {"OK"} )
ENDIF


//added 7/3/16

DbeSetDefault('FOXCDX')

DbeInfo( COMPONENT_DATA, FOXDBE_CREATE_2X, .T. )
DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE , FOXDBE_LOCKMODE_2X )
DbeInfo( COMPONENT_ORDER, CDXDBE_MODE , CDXDBE_FOXPRO2X )

***********************************************************

We are currently testing here using 1.9 with and without those commands that were added.

Rebuilt those same two file, but they had not been updated, so not sure the update has any impact. May have already been damaged for some reason..Ignore this for now. I just updated another client and checked..those two files were fine.

Fred
omni

[omni]

Roger,

Need to re-address this issue.

On the clients using 1.9 they are all getting index errors, all on files rarely used, or work files used for specific menu options that are zapped, reindexed and re-used. In a lot of cases they are corrupt just by opening and attempting to close. When the close all is done at the end of a program an internal data structure is corrupted message occurs. The file index can be replaced, but it does no good. We have to at all times either replace with an empty file, which then works, or bring the file back here and import the data using foxpro. Then it works.
The other thing that happens is that the program will just lock up when the file is opened, or if a reindex is attempted. The only way to get out is to alt-ctl-delete. We use the same method to fix on this situation also.
At this point we do not know if the file will have a problem next time it is used, normally once a week on most of these.

Should we do away with those cdx commands in the on 1.9 clients listed previously on the dbesys, or change them to something else. The 2.0 clients so far have had no issue since the first day.
The other option is to take off the dclip1.lib and dbesys, and have a special start up for the ADS clients, which is not a preferred method.



Fred

[rdonnay]

I won't be able to help you until next week. I'll be available Monday.

[omni]

I thought you may be off somewhere..thats fine. We can get to it next week..

[skiman]

work files used for specific menu options that are zapped, reindexed and re-used

When we have problems as this, we start to check the virsuscanner. There is something that is called 'heuristic protection' which is looking for suspicious actions. Zapping and re-indexing is for this kind of scanners a sign that something strange is happening.

[omni]

We have seen this also and have instructed users that have isolated issues but other users do not..to be sure that our shared network folder has no virus protection. We have seen this work on many occasions on those types of situations. These users were ok until we changed something and it is related to our dll and lib updates. Thanks for you input

[omni]

Roger,

An update on this situation. We have limited this for now to 4 clients and have not updated any other clients. The files that had to be replaced, at least so far, have not repeated the problem. Best laymans description is that the new index methods or library used in dclip1 does not like the indexes created on these small files by prior method, for whatever reason. Always small or empty files used for specific purposes, usually reindexed inside the program as a safeguard due to multiple records being added for a report during an update, and based on user data entry, prints in a specific sequence. Some are just empty files not ever used with an index that has never had any records,

We are very hesitant to update any clients now because they will start getting these errors and get ticked off. Cannot delay that much longer.

Any thoughts?

Fred

[rdonnay]

We are not going to solve your problems by posting on the web forum.

I suggested that we go over these issues on the phone with a Teamviewer session because I don't really understand what you are saying in your postings.