Two files opened exclusive

[Mrall]

In this form the data enviroment has two files opened exclusive(single user enviroment) I set SET EXCLUSIVE ON in the main prg
The jobs curser will delete correctly but, the dispositions curser
won't delete anything. I not sure why.

SET SAFETY OFF  
SELECT jobs
DELETE FOR TRIM(jobs.projname) = jobdel
pack
SELECT dispositions
DELETE FOR TRIM(dispositions.projname) = jobdel
PACK
SET SAFETY ON

 

[Olaf Doschke]

Are jobs and dispositions linked via their projname fields?
TRIM is not ALLTRIM, so do you perhaps have leading spaces in dispositions.projname? Or should it be DELETE FOR TRIM(dispositions.projname) = dispositiondel.

Also what is dispositions? Table? View? No matter what, is it Buffered? Many things could influence why no deletion is done in dispositions.

Bye, Olaf.

 

[Mrall]

Thanks for the response Olaf

Projname in the curser jobs(table) and in the curser dispositions(table) is orginaly placed in each table from another imported file at the same time. So the fields should match. I have compared them and they are the same. I can delete the records from the command window. But for some reason in the method in the form it won't delete the corresoponding records in the dispositions curser.(there are no leading blanks)

Does it have anything to do with the fact that both cursers are opened exclusive?

 

[Mike Lewis]

You say these are cursors. But if they are in the data environment of a form, they must be tables (or views, or cursoradapters).

The reason I mention it is that you ask if the problem is connected with the cursors being opened exclusively. Cursors are always opened exclusively. It's in their nature.

But, in any case, that has nothing to do with whether the records are being deleted. Your DELETE FOR command should work the same, regardless of whether the cursor (or table) is opened exclusively or shared.

The only reason exclusive would be relevant in this case is when you do the pack. But if the files weren't opened exclusively at that point, you would get an error message. Assuming you are not getting an error, they must both be opened exclusively.

Is there a relationship between these tables - either in the data environment or via SET RELATION. If so, that might explain the behaviour you are seeing.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Good idea, Mike.

If there is a relation set the first delete does delete the records, which deletes all records which point to the second table, if the relation comes from there.

So in case this is the reason inverting the order, first deleting in dispositions, then in jobs, would solve the problem.

In general you delete child records first, before deleting parent table/ head data - or - you have cascading delete trigger code in your database.

Bye, Olaf.

 

[Mrall]

I noticed when you view the data enviroment (in the form) jobs and dispisitions are aliases for curser1 and curser2 which are tables I have setup.

The tables are not linked or indexed in any way (although I could and should index jobs on projname). Dispositions has no unique identifer. Dispositions can have many records with the same projname(as well as the rest of the fields may be the same) All the records with the same projname are viewed in a grid when the project is selected from the the jobs grid. (so jobs should be linked to dispositions based on project name) Let me take care of that real quick.

 

[Olaf Doschke]

Well, curso is a very diffuse term in foxpro. In it's main meanings it's a temp dbf as a result of a query, result of a view usage giving a view cursor or result of a cursoradapter cursorfill(). If you use a table that's what's not called a cursor. Still all these ways of accessing data end up in a workarea, which has an alias.

What adds to that is, the visual objects you see in a data environemnt are called cursor, too. This is misleading. These cursors are not representing the data itself, they are actually objects doing the data access. You can create such a cursor object outside of DE on the commandline, eg via o = CreateObject("cursor") and this does not add a new alias into the datasession. It's quite useless outside of a DE. And for example I wouldn't know if and how you could make a DE use a subclassed cursor object instead of the native one, if you add a table or view to a DE. Doesn't matter much, as I tossed away with using the DE anyway, as I only work in classes. But's that getting off topic.

This boils down to the term cursor being used for different things in foxpro and you could argue that everything is a cursor in the end, also an opened table. Like Mike I do differentiate between several types of aliases, though. What's true is, you never work on the files directly, you only work with the workareas. So what's true is, that you work on aliases, and aliases can stand for the different data access types vfp offers. This is rather comparing to very comfortable file handles. Aliases hide the details of the file access done by foxpro, which is needed towards dbfs or views or even remote data.

Bye, Olaf.

 

[Olaf Doschke]

...curso means cursor of course...

 

[Mike Lewis]

Mrall,

Since it's probably your DELETE command that's failing, I suggest you try this:

LOCATE FOR TRIM(dispositions.projname) = jobdel

If it fails to find a record (and you know the record is present), then you will know that the problem lies in the FOR clause.

That way, you can at least eliminate any issues with cursors and exclusivity, and concentate on the reason it fails to find any records to delete.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy