Please address this issue ASAP, thank you!

As Maya wrote, the value of the process currently available in database view far outweighs what I can do while trying to force myself to use webview. Precious time is wasted (I am now part-time and am split between two departments) going back and forth between the views.

This is critically important for day-to-day data management. Queries are a core tool not just for reporting, but for active data monitoring and clean-up. If key fields remain non-editable in Web View, retiring database view queries would significantly slow workflows and make routine data maintenance impractical. Ensuring full field editability in Web View before database view is sunset is essential to avoid adding hours of manual work and to maintain data quality at scale.

Absolutely 100% agree with your statement. They cannot remove the database view without fixing this basic functionality request. We need to be able to view and edit everything in webview that we can in database view otherwise its going to make our lives very difficult. We pay a lot of money for Blackbaud services and it seems ironic that this is not a high priority for them. Get it fixed!

Agree 100%

YES. It is so important because our unique organization (an Abbey, Library, Seminary, Monastery, etc. in one campus) has had to take advantage of every field and field customization that Raiser's Edge has allowed. Since Raiser's Edge is such a well-established rock of a database that many organizations depend upon, it follows that moving it to a Web view would map those fields - including customizations, to their offering.

So happy to see that you are reviewing this. It is a must have! Not including this functionality into WEB view would requires many extra hours of work and frustration.

Use of query as stated below is so varied. And a lot for data maintencance. Can not express how important is it to be able to edit everything in web view and to have all the fields like comments, source, notes, attributes, etc living in web view.

Agree with this post and all the comments too! We need to be able to edit all fields from web view, specifically before losing access to database view.

Having all fields editable in Web View is critical. We cannot move to Web View without it because it will add hours and hours of work. This is an adoption blocker.

We use comments in the gift record to report out restricted gifts. Currently the comment field is not able to be edited after the gift is processed. Therefore any change or miscommunication on the gift cannot be edited to update this.

Please consider also voting for https://renxt.ideas.aha.io/ideas/RENXT-I-8701 to introduce bulk grid editing for all record types! We can ask Blackbaud to replicate database view in web view, but wouldn't it be better if we could IMPROVE them?

Query is not just used as a simple grouping tool to hand off data to Export, Reports, ect. No, Query is used frequently to filter records that need to be cleaned up and adjusted.

Within Query we are regularly opening records and accessing various places on these records to perform needed edits. Why? Because some edits just can’t be done with a Global change/add and creating an Import file is not always practical. As there are many fields which still cannot be adjusted in the Unified View, prematurely shutting off access to Query in database view will make performing needed tasks difficult and unnecessarily burdensome to the customers (us) of Blackbaud.

Customers will now need to have the query open in Unified view and then also have the Database view open to perform such needed tasks -- Unified View Query to filter and group the records on one screen, and Database view on the other screen so we can manually look up and open each record to perform the necessary tasks.

ALL the fields in database view that are coming over to webview at any point need to be viewable AND editable in webview before Query is deprecated in database view. I have no understanding of how your development team would think it would be ok to turn off access to Query in database view before you have replicated all of the functionality that database view query is linked with.

We use comments on telephone, email, links, etc. for several data review functions and these aren't available in any way yet in webview. If the field isn't available to add to a query in webview and we can't get to query in database view, then we lose all ability to use those fields effectively.

Global changes, Exports, etc. in database view need access to query in order to process.

This is really important. I think many of us still find ourselves in database view because there is so much we still can't edit in webview.

We just can't lose query access in DB view before the fields are editable in web view. It's just nonsense to imagine we could do our jobs properly without it. If I could amplify Brent Reed's comment, I would. Maya Rosman has highlighted multiple reasons and multiple fields that are absolutely critical to be editable in web view before db view query is retired.

Honestly, this should be the LAST thing removed from database view.

I've found another field I need to be able to edit in webview that we currently cannot edit. Right now I can see my Education Custom fields in webview, but when I click to edit Education information in webview, I cannot access my Custom Fields. Sometimes we need to make corrections or changes to these after the initial data entry. If I found that a student had been entered without our school ID, I would find that through query, and then seek to add it to their current school's record. Right now in webview, once an Education record is added, you can no longer add custom fields to that education entry or edit the ones that are there. The only way to add the new custom field would be to add an entirely new education record, but most of the time we just need to update a current education record. This is a data integrity issue.

Popping back in to add another missing piece of functionality that I need to exist in webview before query goes away in database view. We use an outside system to process online giving. Our gift processor enters those gifts into RE for us. I run a weekly query to cross-check that that data entry is correct - especially the gift dates. When the gift date in RE does not match the gift date in our online gift system, it causes reconciliation problems with finance. It is VERY easy to accidently miss changing a gift date when doing entry. That's why I have the data monitoring process.

I've been trying to do this in webview query as much as is possible. And it works fine when all data is correct. HOWEVER, I have a gift that was entered as 8/6/25 and should have been entered as 8/5/25. The gift date is not an editable field in webview, which means I now have to open databse view, search for this gift and adjust the gift date there. This gift is not posted and is fully editable in database view, but in webview I cannot access the field.

Gift date editing is critical to our coordination with finance and will impact our audit if we do not correct all dates to match.

I've been reading through the comments and I understand where everyone is coming from (side note: we are VERY passionate about this issue) -but that's from the perspective of someone who regularly handles the daily grind of data cleanup using Database View Query. I'm not sure the core issue is coming across clearly to those who don't work that way, so here's my attempt to explain what we're trying to convey.

I think what may not be clear is this: for those of us who use Query to manage and clean up groups of records, it's essential that clicking on a name in Web View Query drills through to and gives us full edit access to the entire record—just as it currently does in Database View.

If Query in Database View is retired before all fields become editable in Web View, it will force us to constantly switch between interfaces (not everyone has dual monitors) and manually re-search for each record in Database View. This isn’t just inefficient—it’s a major productivity hit, adding unnecessary steps to already tedious work. Plus, Web View is already painfully slow enough when updating records, and adding this extra layer of friction for those of us doing hands-on large scale data cleanup and management is borderline inhumane. (Yes, I know that’s hyperbole—but only slightly.)

Absolutely needed!