Hello
I use AIS to connect ADT/ADI database/index for remote access.
Now, I want to make reindex my ADI like CDX.
So I need to delete ADI file or delete TAG name.
How to know or get this ADI Tag name function or delete Tag name?
Anyone have good solution or idea for this?
Thank you
Regards,
Richard
How to check ADI Yes/No Exist index TAG name?
You should not need to perform any reindexing task, I mean, you don't need to reindex any table since ADS indexes should not cause any problem at all.
Anyway, if you want to "reindex", do the following:
Close all opened tables.
Manually erase all the ADI files (FERASE("file.adi")
Perform the index as usual
you are done.
Try to avoid the reindexing, I repeat, you don't need to reindex since you are working with ADS.
Anyway, if you want to "reindex", do the following:
Close all opened tables.
Manually erase all the ADI files (FERASE("file.adi")
Perform the index as usual
you are done.
Try to avoid the reindexing, I repeat, you don't need to reindex since you are working with ADS.
Saludos
R.F.
R.F.
- Badara Thiam
- Posts: 160
- Joined: Tue Oct 18, 2005 10:21 am
- Location: France
- Contact:
Without ADS also, if you open each index before every time youRF wrote:Try to avoid the reindexing, I repeat, you don't need to reindex since you are working with ADS.
upgrade yours databases.
Regards,
Badara Thiam
http://www.icim.fr
http://www.icim.fr
-
- Posts: 20
- Joined: Fri Oct 14, 2005 7:56 am
But to answer the specific question:
All the standard ord* rdd functions should work: ordDestroy, ordName, etc., as well as their commands like DELETE TAG. Also:
dbOrderInfo(DBOI_ORDERCOUNT, cBag), etc.
Still, I also think it's best to delete the adi file.
And the other comment on the forum re not needing to reindex as long as you open indexes before updates I feel is wrong. Rene's point is that IF you are using a data server (SET SERVER REMOTE) you don't need to reindex. ANY shared file rdd (including ADS with the LOCAL server) IS unavoidably subject to index corruption no matter how careful your code is.
All the standard ord* rdd functions should work: ordDestroy, ordName, etc., as well as their commands like DELETE TAG. Also:
dbOrderInfo(DBOI_ORDERCOUNT, cBag), etc.
Still, I also think it's best to delete the adi file.
And the other comment on the forum re not needing to reindex as long as you open indexes before updates I feel is wrong. Rene's point is that IF you are using a data server (SET SERVER REMOTE) you don't need to reindex. ANY shared file rdd (including ADS with the LOCAL server) IS unavoidably subject to index corruption no matter how careful your code is.
-BH
Reading carefully I noticed that you are using the AIS, so things may change:
If you are using AIS you are using ADS Remote Server, so you don't need to perform any reindex operation at all.
Reindexing erasing the ADI files is only possible when you are working in a LAN, because the AIS doesn't have direct access to the files in the remote server.
And Bryan says, if you are using the local server, you are still in danger of index corruption
If you are using AIS you are using ADS Remote Server, so you don't need to perform any reindex operation at all.
Reindexing erasing the ADI files is only possible when you are working in a LAN, because the AIS doesn't have direct access to the files in the remote server.
And Bryan says, if you are using the local server, you are still in danger of index corruption
Saludos
R.F.
R.F.
-
- Posts: 1033
- Joined: Fri Oct 07, 2005 3:33 pm
- Location: Cochabamba - Bolivia
-
- Posts: 20
- Joined: Fri Oct 14, 2005 7:56 am
Generally speaking, I strongly recommend staying with the clipper-compatible standard commands and functions. In the early days of rddads there was a need to create some wrapper functions to directly access ads stuff, but now almost all functionality (except where an ads feature is beyond what the common rdds offer) is integrated into the core rdd and routed correctly to ads.
It keeps your code cleaner and makes it less ads-specific.
It is ALWAYS a good idea to review the ADS help file to understand the underlying functions and features.
It keeps your code cleaner and makes it less ads-specific.
It is ALWAYS a good idea to review the ADS help file to understand the underlying functions and features.
-BH