2

I'd use the API if having the choice, but right now I don't have the time for a learning curve, so I'm doing direct:

UPDATE       VersionedFields
SET Value = 'Hypothesis Testing' 
WHERE Id =  'B8B9465E-1FB9-4717-BE14-0524DA1B4630'

in preparation for bigger batching to come.

However the change is not showing on the page, after browser reload and browser cache clearing.

No "Publishing" action is involved because the test site points on the Master database (so from "Content Editor" a simple Save is enough to show the change instantly on the Web site pointing on Master).

Also when I open a fresh /sitecore "Content Editor" after a SQL direct UPDATE, this is still the old value from before my UPDATE that shows.

So I know that it's not reading directly from the DB even when starting a new Editing session, but from some cache. I had tried a:

/Sitecore => Control Panel => Database => "Rebuild search indexes"

on my local box, but it had done just bubbles.

I must not be very far and will continue to search for answers, but in the meantime if one knows how to trigger the DB change to finally show on the page, I'll take that!

Improve this question
2
  • I know this is not a valid answer for you, but with the best of my intentions I can only suggest you to avoid going down that route and always handle Sitecore's data via Sitecore's API (Client or Server)
    – Vicent Galiana
    Commented Nov 29, 2016 at 17:11
  • @VicentGaliana I have converted your answer to a comment. The reason is, your post does not answer the presented question, although it is still relevant as a comment.
    – Dmytro Shevchenko
    Commented Nov 29, 2016 at 18:08

1 Answer 1

Reset to default
4

As already mentioned, and you are probably aware, what you are doing is really not a good way to edit data. But to fix your issue now: Sitecore does cache data. So you will need to clear those caches to see your changes. You can use ../sitecore/admin/cache.aspx to clear caches. Or restart your site to clear everything ;)

Improve this answer
3
  • YES that did it! Thanks much. I'll do more readings on what are valid reasons that support the case for not eating with just a fork and a knife when you need to, but only with a spoon tied to another spoon itself tied to the fork for the left hand, and a spoon tied to a fork tied to a knife in the right hand ;)
    – Coeur Dusite
    Commented Nov 29, 2016 at 18:13
  • @CoeurDusite The reason is, when an item has already been requested by Sitecore, it caches it in memory. It is much, much faster to access the item from cache than to make a database query. If the item is edited from Sitecore, then it knows to update the in-memory cache. If you manually update the item in the database, there's no way for Sitecore to know it's been changed until it makes a database query. This will only happen when you clear the cache, or reboot the application, or if that particular item gets updated through the Sitecore API.
    – Dmytro Shevchenko
    Commented Nov 29, 2016 at 18:40
  • Thank you, no question caching is good to have, I was wondering of the reasons behind avoiding direct SQL and then this associated ../sitecore/admin/cache.aspx reload. Often so there is a pattern where one repeats what they've heard, but without a firm knowledge of the reasons behind. In our case, "because it compromises the database integrity" would for example certainly be a valid reason. But if it's only because you need to trigger the cache reload manually, I can live with that. Temporarily, for my one time batch insert/update.
    – Coeur Dusite
    Commented Nov 29, 2016 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.