Using SQLServer2000 for ReportExplorer

rbuser

Using RB 6, D5, WinXP.

I'd like to use ReportExplorer as a report menu. The doc shows how to set
up InterBase for this, but I need to use SQLServer2000. I've tried to set
this up, but there are some differences that seem to get in the way. I've
set up the two tables exactly as specified with the indexes specified.
Since SQLServer only has After triggers, I've tried using identity fields to
simulate the auto-incrementing keys fields required by ReportExplorer. This
doesn't work. The app runs, but when tyring to add a folder I get "Field
FolderId must have a value". When trying to add a report to the "All
Folders" folder, I get "Cannot make a visible window modal".

Any ideas?

--
Alan.Leiter@wcg.org

digitalmetaphors

Please post only once.

Please take a look at the installed SQL Server 7 demo. There should be a SQL
script you can run. We are using it here on our SQL Server 2000 database.

..\RBuilder\Demos\End User Databases\SQL Server


Cheers,

Jim Bennett
Digital Metaphors

rbuser

Thanks for the reply! Sorry about the multiple post - my newsreader was
giving me fits.

I found the SQL Server 7 demo and ran the script to populate the tables.
Then I proceeded to compile and run the demo end user app for SQL 7. It
came up and ran fine. I then turned on all the TReportExplorer ItemOptions
and FolderOptions so I could add, rename, delete and move folders and items.
That's when the fun started. I haven't been able to detect a pattern, but
ReportExplorer does not consistently reflect all of these activities, e.g.,
renaming and moving will not be reflected in the explorer panes, or will be
reflected in one, but not the other. And they are not consisntently
reflected in the actual folder table. The window may show a folder to be
renamed or created, but the folder table does not show it. At such times,
if I proceed to move something into such table or move the table itself, it
results in very strange re-arrangements of the folder hierachy, sometimes
resulting in folders being assigned a parent of -1 in the table, but showing
up in the explorer pane as being under the root or disappearing altogether -
not even under Recycle. At other times trying to move the folder to where
it should really be results in the message that the folder is already there,
do I want to replace it? If I answer yes, all contents of the moved folder
disappears from the database! After getting the display into such a mess,
even after restarting the app, it does not show the hierarchy that actually
exists in the database.

In scrutinizing the demo app I found that the BDEPipeline objects'
RefreshAfterPost attribute were set to False, while the doc for the app says
to set them to True. I set them to True thinking this may solve the
problem. However, this only made it worse. In addition to not reflecting
the user's actions it also generates an error saying something like "This
action is not allowed because the table does not contain a unique index".
Which is not true, since the SQL script created a primary key - which I
confirmed. Even though it gives this message it really does proceed with
the action and the database shows the update. However, the explorer panes
do NOT show it. In fact, at this point if I activate another application
and then return to the Report Explorer window, the entire folder pane is
blank and nothing will restore it. Only exiting and restarting the app allow
the updates that were actually written to the table to show up.

Is there an updated version of ReportExplorer that works better? Or, am I
missing something fundamental? Let me know. ReportExplorer looks like a
very nice, simple way to present reports to the users, and as a static menu
system. But I would hate to have to build a separate interface to allow
developers to set it up in the first place.

Thanks.

--
Alan.Leiter@wcg.org

digitalmetaphors

It works fine for us here. What steps do you take in the report explorer as
a user to reproduce this behavior?


Cheers,

Jim Bennett
Digital Metaphors

rbuser

I've reinstalled, recompiled and reproduced the same behavior. I will
submit my findings to the email support since it is somewhat lengthy.
Thanks for your replies.

--
Alan.Leiter@wcg.org