Why some records are not read byt the server? 7

[Mandy_crw]

Hi everyone... i have this code...

SELECT pendlag

IF FLOCK()
flush
if !eof()

GO top

DO WHILE !EOF()

​

If tsulat.status = "Inactive"​

DELETE

​

endif​

SKIP
ENDDO

UNLOCK IN pendlag
ENDIF

in the pendlag, it is populated by two client computers, when i browse the pendlag table, i see all those added by the two client computers, but only those added by the server is being deleted, all other records added by the two client computers are not? How to refresh the tbale so that all records added by the two clients are recognized? Please help me find answers... Thanks and God bless....

 

[Chris Miller]

I need more information to help. What you do seems over the top, here.
You don't need a file lock to do delete operations. Flush also rarely helps to write out changes. If changes are buffered, only Tableupdate() stores them, no fllush, not even flush force does so.

What's very unclear is how pendflag is related to tsulat. You make your deletion depend on tsulat.status, while you loop through pendlag records.
If there is no relation, the tsulat record you check stays the same, so it's either delete all or none. And I bet that's not what you want.

If there is a relation from pendlag to tsulat that would explain it, but then please also post that.

Chriss

 

[Mandy_crw]

oh sorry Chriss... that one error I've made, I intend to delete all that's put by the two client computers with "Inactive" status... it should be alltrim(pendlag.status) = "Inactive" that I should be deleting... i have no problem if its being add by the server itself, it can be deleted... but coming from the two client computers, the record is there but i think its not being recognized or read that's why its not deleted... the Tableupdate() ive tried but still nothing happens...., thanks Chris...

 

[Mike Lewis]

Mandy,

It's not clear what you are doing here. You appear to be looping through Pendlag, but deleting records based on a condition in another table (tsulat). Are you sure that's what you want to do?

In any case, you can greatly simplify the code by replacing the loop with a single DELETE. Perhaps like this:

DELETE FROM Pendlag WHERE tsulat.status = "Inactive"

That way, the table locking would be done automatically, so you wouldn't need to FLOCK the table.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Mandy,

if it was an error to check tsulat.status = "Inactive", then this should also explain why some records are not deleted.
A DBF doesn't know from where records came, a delete will not even be able to make such a distinction.

If it's pendlag.status, then all you need is a

DELETE FROM pendlag Where status="Inactive"

That replaces all our code, it's really just one SQL Delete.

What records remain which should be deleted? If they have "inactive", pay attention to VFP being case sensitive. If that status is about active/inactive only, it would better be a non-nullable logic field.

Is there server code at all, a server side EXE? The usual VFP multi client application will not use a server for more than sharing the database files and perhaps an update folder with the newest executable. But you don't have a server executable, you just share DBC and DBFs and further memo and index data files.

I don't know, but maybe your whole problem is that you made a setup generating an application and database folder for every installation, and all users have their own local database and nothing is shared. In multi user client server database applications, the clients usually don't get a local database installed, they get configured to a central database share and that's where you once install a database for all clients. You can have a mix of some local data, for example configuration data, only necessary separately, for each client their own, or a local database of views, but you will always also have a majority of the shared data on a central file share. And shared data needs to be on a server side file share.

Sorry if that's already obvious and not your problem. But it seems to me also remembering your question about how to determine the growth of a table that you simply not knwo what you're doing and are astonished about missing data that has the easiest explanation of not being saved to a server dbf from clients at all, as each client has it's own DBF.

Chriss

 

[Mandy_crw]

Hi Chriss and Mike.... Thanks for your suggestion ive done and followed your codes... but only those added in by the server computer were deleted... but those added by the client computers, even if the status is inactive, its not deleted.... I wonder why...

 

[Chris Miller]

Please take a close look, whether there are spaces, Small L instead of big I "inactive" instead of "Inactive" or other differences.
And then we don't even know how you generate or update records from clients vs from the server. There seems to be a difference, as you explicitly mention it again and again. Why isn't it the same code? There's nothing special about generating records in a DBF that differs from client adding to a DBF in the LAN vs server adding to a DBF on a local drive (local to the server).

It's the same APPEND BLANK or INSERT you do to get a record. It's the same REPLACE or UPDATE to change the status field.

If there are differences in code acting from clients and servers, then your problem likely isn't the network or locking or such things that made you try flushing, do you use the same code? Do you have a client exe and a server exe? Are there two separate projects for compiling them? Did you copy code instead of just using the same code, the same PRGs, for example, embedded into both projects? Because that's what should be done, no copies of PRG that will only change for client or server when you only change them in one of the two PJX.

And to conclude, if the status field contains "Inactive" - exactly that - then the records will be deleted by the DELETE statement, no matter where the record came from. If you don't see a difference, then look closer, look into the binary representation, look into things like TABS and other characters unseen but making a binary difference. You have to be very precise here.

Chriss

 

[Mike Lewis]

How it interprets the expression [tt]status="Inactive"[/tt] also depends in part on whether you have [tt]SET EXACT ON[/tt] or [tt]OFF[/tt]. And also whether the word "Inactive" fills the width of the field or is padded with spaces.

What I would do in case like these is something like this:

DELETE FROM pendlag WHERE ALLTRIM(UPPER(status))="INACTIVE"

That way, you are covered for case sensitivity and padded spaces.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

To be fair, Mandy already thought of alltrim and posted

alltrim(pendlag.status) = "Inactive"

But in the end neither ALLTRIM(..) nor ALLTRIM(UPPER(...)) are caring for all eventualities that could cause wrong status detection.

So I once more point out the other thing I mentioned, if this status field it's just for active/inactive you better make it a Logical field that can't be half true or false. If it's one of several states, then you could make it a choice from a combobox that displays several state words each associated with a status number and actually only store the number 0,1,2,3, however large the range may be, and what is inactive then simply depends on the position of the "inactive" item in the picklist.

Make life simpler by avoiding any inconsistencies due to users mistyping, for example. If the only difference from client to server is the server writes "Inactive" by code whereas you store what client users write as status, then anything that simply has a typo like "incative" is not found, of course.

Chriss

 

[Mike Lewis]

if this status field it's just for active/inactive you better make it a Logical field

Absolutely right.

And if there are more than two settings, an integer would be a better choice. For example:
[tt]
0 = Inactive
1 = Active but dormant
2 = Fully active
3 = Pending
4 = Whatever[/tt]

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mandy_crw]

HI Mike and Chriss.... I've read and followed your suggestions!!! It worked!!!! Thank you so much...

Thanks myearwood for you enlightenment....

 

[Mike Lewis]

Forum members,

I have just red-flagged a message in this thread, posted by someone called cuteValeria. I hope by the time you read this, the forum management will have deleted that message. If not, please ignore it.

This kind of spam is fairly common in some other parts of Tek Tips. It would be a shame if it became prevalent here in the Foxpro forum. So, if you see any similar postings in the future, please help by clicking the Report button in the bottom-right corner of the post.

You can easily recognise spam postings because they seek to advertise or promote some dubious product or service which has no connection with the subject of the thread. They typically contain links to spurious sites. Another sign is that the person posting has only signed up to Tek Tips on the same day and have made no other posts (you can check that by clicking on the person's name to view their profile).

Please help to keep the forum free of spam by reporting any dubious posts.

UPDATE: I see the offending message has now been deleted. Good.

Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I also already reported this as spam.

Chriss

 

[Steve Meyerson]

Me too.

Steve