It is possible to use in vfp 9.0 a foxpro Dos dbf even when this one is in "Exclusive USE"

[titoneon]

Hi Everyone,
I am trying to create a new project that will handle some free tables some forms, reports etc, the problem is that i want to updates those free tables from some foxpro dbf files that are in use during the whole day and sometimes in "exclusive use " the problem is, i want to have always data that is current in the vfp table from the Dos dbf files, i know that is probably not possible and the only way is to update them by night using a scheduler batch file to append from the dos dbf into the vfp 9.0 spk 2 tables.
Any suggestion to be able to do this during the day while the Dos dbf files are in use in Exclusive USE ?
Thanks
Ernesto

 

[Mike Gagnon]

Exclusive means only one person at a time can use the table, and that does not seem to be you. The question is why are they opened exclusive? Can that part be changed?

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[Olaf Doschke]

Also, what does "sometimes" mean?

If it's really just sometimes, then that's maybe not intentionally dbfs used EXCLUSIVELY but merely shared and currently written to.

I assume you have no control about the DOS app, only your new VFP9 app. What your synching should not do is copy over the full data in an endless loop, then YOU are stressing the DOS system.

Actually you can work on DOS DBFs inside VFP9, there is probably a higher chance to work shared on that data, when you change your new VFP9 apps to work with DOS codepage, there is STRCONV() to convert texts for a windows app working on the same data.

Bye, Olaf.

 

[titoneon]

Mike,
Yes that can be change, but the FOXPRO DOS has so many modules that whoever did that put in the code a bunch of "index on so+so TO whatever", also there a lot of "pack commands" too, all of those need a Exclusive use, so i was looking for someone that was into the same ship i am and find the way around, i know in Exclusive use , the dbf can be use only once.
Thanks

 

[titoneon]

Olaf,
Yes i have access to the Dos Foxpro, what i want to do is access or dislay information from the dos app in vfp 9.0 app but if those tables at a particular moment are in exclusive use then the users from vfp 9.0 app will get access denied, you will say WHY ? Cause the person who uses this Dos App sometimes use some modules that pack data, index data, so that could be any time during the day, then this is going to denie access to the VFP 9.0 APP, i guess the only choice i have is to revise the 80 modules and find each "index on " and change that, also create a batch file that runs at nite to do the packing, i don't see any other way
Thanks

 

[Mike Lewis]

Ernesto,

Given that the DOS app is constantly indexing and packing the files, then they clearly have to have exclusive use, so you can't access them from your VFP app.

The best solution would be to modify the DOS app so that it does not pack or index the files - at least, not during the day. Can you do that? Do you have access to the source code, and are you able to modify it?

If you can remove the packing, that shouldn't affect the functionality of the DOS app. It might make it a little less efficient, given the files will be larger than they would be otherwise, but that's not likely to be a big problem. In my experience, developers often pack files when they don't really need to, and that could be the case here.

Removing the indexing might be slightly more difficult. As I'm sure you know, you don't need to recreate the indexes every time you use them. Just create them once at the outset, and then SET ORDER as needed. Some developers don't realise that, and are constantly issuing INDEX commands when they don't need to. If your DOS developer does that, then you should be able to simply remove the indexing. But you would have to study the code carefully in order to be sure.

If you are not able to modify the DOS app for any reason, I'm afraid I can't think of any other solution.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Mike Lewis]

Actually, one other possibility comes to mind, but it's not a very elegant one.

In the DOS app, immediately before you open a file for exclusive use, copy it to a temp file. Then delete the temp file as soon as you finish the packing or indexing. In the VFP app, try to open the file as usual. If you get a "file is in use" error, look for the temporary file and use that to update the VFP app instead of the real file.

In fact, you won't lose any concurrency by this technique. The data will be completely up to date at the point at which you make the copy, and it can't be updated before you delete the copy because the app will be busy packing or indexing at that point.

Not a great solution, I admit, but worth thinking about perhaps.

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[titoneon]

Hi Mike Levis,
That is not a bad idea since it is easy to know the dbf files i need and just create a temp file for the purposes of view it the actual data but afer the pack i will need to recreate the temp file again cause now the previous temp it is not like the dbf that was pack, so i can have different users accesing the temp file before the pack and in between thee pack and probably just after the pack so that means i will need to do something to create another temp file after the pack right away Right ?
Thanks

 

[Mike Lewis]

Yes, I guess that's right. You would have to create a separate temp file for each file being packed. And you would have to create each one immediately before the corresponding file goes into exclusive use mode. But once it's no longer in exclusive use, you wouldn't need the temp file any more (as far as I can see).

But these are details. If you think the general approach will work, you will need to look at the whole idea more closely.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[mm0000]

Titoneon,

Just to let you know "index on so+so TO whatever" to create idx files does not require exclusive use of tables.

 

[Olaf Doschke]

mm0000 is right, and PACK is not needed at all, if you just keep SET DELETEED ON. It only would "compress" data a bit. I'd go about nonexclusive use of tables of the DOS app, then you can share data with a windows app.

Bye, Olaf.

 

[Mike Lewis]

"index on so+so TO whatever" to create idx files does not require exclusive use of tables.

True. In fact, you don't need exclusive use for any use of the INDEX command - only for REINDEX.

Having thought some more about this, I'm inclinded to agree with the others. Better to remove the need for exclusive use, rather than the kludge I suggested.

Given that you don't need exclusive use for indexing, and that you can forego packing without any loss of functionality, I'd say you should aim to remove the exclusive use. That can't be hard to do. A code references search for "exclusive" should locate all the instances of it within the application.

That would solve the problem without having to do the complicated stuff I suggested with temp files.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[titoneon]

Yes you guys are right but i don't know why the previous person who did that in Foxpro dos, he put a lot of reindex, so i will probably have to look for all the "index on" and replace them for "set index to " and remove the "Reindexes" command and about the "pack" i was thinking as Olaf said to "set delete on" and then so they don't get shown on some browse then create a routine that runs once month to the "Packing" over night.
Sound like a good plan, if am missing something or the "SET INDEX" is imcorrect , please correct me
Thanks

 

[Mike Lewis]

There are a couple of further points here.

First, does the DOS app use IDX indexes or CDX indexes? If IDX, it would make sense to go over to CDXs. That shouldn't affect any existing code. But it will mean that you can use SET ORDER TO rather than SET INDEX TO, and that will be simpler and (I think) more efficient.

You say you will remove the REINDEX commands. Good, but check first why these commands are present. Does the application actually require the indexes to be re-created for some reason? If so, use INDEX ON rather than REINDEX to avoid the need for exclusive use. Or, has the developer added the REINDEX commands in the belief that they will somehow increase the app's reliability or safety? If that's the case, you can probably get rid of them altogether (but do test the app carefully if you do).

Finally, doing the packing overnight is definitely better than doing it when things are busy. But, depending on the circumstances, you might only need to do it once a week or once a month. In my experience, developers tend to pack much too often. Unless you have a very high deletion rate, it's rarely necessary to pack every day.

Let us know how things work out.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[titoneon]

Mike,
Almost all indexes are IDX and just a few CDX, so if i have IDX i have to use "SET INDEX" is that correct? if i have some CDX then i will be able to use "SET ORDER TO" IF this type of index was used "INDEX ON KEYFILED TAG NAME" is that correct ? , yes i will check why "REINDEX" was issued if it is needed, i will issue the "Index on " command according, let me know if there is something wrong in this post
Thanks

 

[titoneon]

sorry misstyped KEYFIELD and i put KEYFILED

 

[titoneon]

Sorry again, yes i can use "set order to" for IDX and for CDX

 

[Mike Lewis]

I've always used SET INDEX with IDX indexes, and SET ORDER with CDXs. But I've just reviewed the Help for these commands, and it seems that you can use either of them with both kinds of index.

SET INDEX lets you specify which index files (IDXs) you want to open, whether or not you want to make one of them the controlling index. With CDXs, you don't explicitly open the index, as it is opened automatically when you open the table. For both types of index, SET ORDER specifies the controlling index.

In general, SET ORDER is preferred because it's more up to date. However, this has really got nothing to do with your overall strategy for dealing with exclusive use. Whether you use SET INDEX or SET ORDER is really just a detail.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[titoneon]

Thanks one more time Mike, i will keep you posted, as soon as i put my hands on it
Ernesto

 

[TamarGranor]

One really good reason to switch to CDX and specifically, to one structural CDX file per table is that it will keep all the indexes up to date. I'll bet one of the reasons for all that indexing in the code is that whoever wrote it is allowing indexes to get out of date by not having them all open every time the table is open.

Since FoxPro 2.0, there's been no reason to maintain IDX files.

Tamar