I haven't looked at this exhaustively yet, but it looks like RList in v7.21 is picking up the %RECORDS% record in a quickdexed file.

When I exec TCL and do:

LIST SP WITH LAST_LOGIN NE LAST_LOGIN or SELECT SP WITH LAST_LOGIN NE

LIST SP LAST_LOGIN

results include the %RECORDS% record

The same from the System Monitor if I:

RUN RLIST "LIST SP WITH LAST_LOGIN NE '' LAST_LOGIN",0

If your .DBT file was created before the Quickdex was added, and has not been updated, then %RECORDS% will show up. Also, the quickdex will not be updated correctly. This is because OI (AREV did this too) is using the .DBT image file to create the file handle. The .DBT file is missing the entry for QUICKDEX.MFS.

Another possibility is that you are using an MFS of your own creation, and the MFS list is out of order. Your MFS must be first in the list, while SI.MFS and QUICKDEX.MFS must be right next to the BFS RTP57.

Quickdex should have been on there before the DBT was created as it has been on there at least 10 years under ARev.

I'll take it off and put it back on in OI and see what happens.

No MFSes other than SI.MFS.

Well, removing Quickdex and adding it back on seems to have solved the problem.

It's the same problem you have in ARev when using Quickattach to cache file handles. The price to pay for effeciency.

Thanks, something more to keep under the hat.

QuickAttach had an option to rebuild/refresh the cached attach images from the current file handles. Is there a similar function in DB Manager (other than detaching all the files and reattaching them and saving)? If not, this would make a nice enhancement also with an option to delete invalid volumes.

Warren,

I wrote a function, MANAGE_DBT, which maintains multiple database images in an account and can create new images, delete images, switch images, etc. I also wrote indexing and MFS installation programs which automatically clear database images when file changes occur. My login process creates new database images when the images are missing. As a result, I never use the DB MANAGER. But why not?

The DB MANAGER assumes that only one set of data tables exists for an application. Frequently, always with my applications, multiple databases are required for an application, which contradicts a fundamental aspect of the DB MANAGER. I suggest that asking Revelation Software to fix the details of a conceptually flawed component is pointless. If you need ideas or code to manage .DBTs while bypassing DB MANAGER, let me know.

I have yet to understand the benefits of using the DBT at all apart from, perhaps, the system files in SYSPROG which never change.

We had no end of problems with it at first (as also with the quick attach in Arev). We therefore include in the log-on an instruction to attach the required volumes. With modern kit I can't see any difference at all in log-on time. It's dead simple and we've never had a problem. The only thing we had to tweak to prevent DBT being messed up was the RDKMODUKEINSTALL program.

As a bonus we have users who need several separate similar databases for different clients. Logon asks which and attaches it. Button on main menu asks which next, detaches current client and attaches next.

Maybe I'm missing something!

Sounds like some utilities to submit to the Works CD :)

Gerald,

I suggest that asking Revelation Software to fix the details of a conceptually flawed component is pointless.

I would suggest that this sounds a bit harsh. I don't think you meant it that way as you have been publicly very appreciative of Revelation's responsiveness to improving the product. As "flawed" as it may be for some, I would say that the vast majority of our applications have happily lived with the current model. We would welcome a more robust method for database management as you are proposing, but Revelation has quite clearly advertised that whenever a workaround (commercial or freeware) is available that allows OI to do something different/better, then they would prefer not to re-invent the wheel. Rather, with their finite resources, they would prefer to focus on things that only they can fix or improve upon.

[email protected]

SRP Computer Solutions, Inc.

Don,

It was not my intention to offend anyone. However, I have supplied developers with sample code for .DBT management several times during the past year because of the conceptual limitations in DB Manager. I conclude that many developers would feel dissatisfied with bug fixes only, when they find the component's design approach needs to be reconsidered.

This is not a slam against Revelation Software. Gosh knows that they have enough on their plate. They inherited the DB Manager design when they took over the OI product. Developers who needed a different approach to the DB Manager were working around the limitations then, and they will continue to. Meanwhile, we have CTO, OIL, Universal Driver, 32-bit, etc. Revelation Software should continue to do this wonderful work, and maybe the issues with DB Manager can be ignored BECAUSE DB Manager is an unnecessary component of OI and its problems are conceptual, not bug-related.

Please, please do not think that I intended to speak harshly of Revelation Software.

Gerald

Warren,

A complete utilities demo should be on the WORKS cd. If not, write me and I will see about forwarding it to you.

Gerald

[email protected]

Seemed a little harsh to me, but I brushed it off for the very reasons you mentioned.

We can't be all things to all people, and I glad to see that folks like you and Don know that.

See you all at Spectrum next week!

when creating a table or deleting a table .. does the dbt get updated? Would this be possible without a lot of work on the part of RTI?

Dave,

Suppose RTI added this feature. Maybe it should be applied through a volume MFS … in which case you could just as easily write the MFS yourself. Then, what about temporary tables? Should we take the .DBT creation hit with each table? Or, maybe we copy a table to DATAVOL while restructuring it. Should this be added to the .DBT? What about multiple data volumes used in the same application. Would the .DBT updater know how to update all the images at once? How long would that take?

You suggest that this would be an easy fix, but I think not.

Gerald

Dsig,

Normally when adding an MFS to a table in an update, I would do the following to update the .dbt:

Detach_Table(Table)

Attach_Table(Volume, Table, Application)

Define_Database(Application, Yes$, "", "")

This has worked fine in past situations to force the .dbt to get updated in runtime systems.

[email protected] SRP Computer Solutions, Inc.

1) would you point out where i suggested that this would be easy

2) the dbt is primarily the tables array (yes not exactly .. i know .. you can point out the bits different if you want)

3) one our apps (not live) has 1196 tables (as noted when dbmgr starts). It takes approx 5.5 seconds to save off. Now 5 seconds is a while BUT how many times are tables created. I believe that the license does not allow the creation of tables. I am not sure about deleting them but doubt that the this would be against the law but how many times are tables be deleted.

4) yes i can write another MFS but what about joeblow .. the new OI guy who creates and app .. a dbt and moves on only to find later that the dbt is not up to date. Guess we should have the docs state that creating a dbt is a good idea but just be sure to maintain it yourself.

Maybe i should check my SqlServer database and be sure that it is keeping a good catalog of the tables available

I understand that if there is a workaround it should be lower on the stack of things to do BUT there are somethings that should be complete .. at least in my mind.

cool .. that might even be something i would do ..

and there is a reason that YOU have to do this? a reason that Set_MFS does not handle this itself?

can you show me in the docs where it talks about this?

like i mentioned in another post ..i will check my sqlserver dbs to be sure they are tracking correctly

I don't know if Set_MFS was as complete a function as to also update the .dbt file, so to make sure I always added the additional commands.

If you look at the documentation for Set_MFS, in the "See also" section, the first listed command is "Define_Database".

[email protected] SRP Computer Solutions, Inc.

]]I don't know if Set_MFS was as complete a function as to also update the .dbt file, so to make sure I always added the additional commands.

always wise to expect the function to be less than complete. if not you can be surprised

]]If you look at the documentation for Set_MFS, in the "See also" section, the first listed command is "Define_Database".

yep .. now just need that documentation to explain to new people how to complete the function or what will be missing

This seems like an easy enhancement for Rev to make to Set_MFS. Add it to the suggestion box :)

This should be an "on-demand" utility much like LH_Verify or reindexing/syncing the System Index/Database/Store Procedures, so execution time shouldn't matter that much/

It could have several levels of scanning: basic through comprehensive

Basic scan would just look at what's currently in the DBT, read the REVMEDIA entries and rebuild the handles from that.

Comprehensive scan would confirm existance of the directories and revxxxxx.* files at the OS level.

I wrote a utility in ARev ages ago (CLEAN-ACCOUNT) that does the last part. It even finds REVxxxxx.* (orphans) that are in the directories but not in the REVMEDIA file.

I suspect that the DBT had it's origins with the QuickAttach feature that is in ARev v3.x, which has it's own flaws: namely it doesn't always refresh the QA image even when forced to. The original QuickAttach utility from Stephen Thomas at Dunbar & Associates had a much more comprehesive rebuild/refresh function.

QA was a great time saver with slower networks/servers/workstations Anybody else remember running Novell 286/386 with an ArcNet backbone?) and those forever attach times in ARev v2.0x?

With today's hardware we don't really need QA.

View this thread on the Works forum...