WELCOME TO THE COMMUNITY
find what you are looking for or ask a new question
Home > Forum > Latest posts

latest posts

MVP
In reply to: Jacek Wojnar

Good to know ;)
I must have missed something, or I'm relying on outdated information.

Hi Jacek,

from a technical point of view it was always working but license agreement didn't allow it.
As far as I know this has changed over time and it's now allowed but I don't find something where this is explicitly stated.



Best regards,
Daniel

Hi,
Running SDK extensions is possible in the WEBCON SaaS Multitenant environment.
Although the infrastructure is multitenant, each customer's applications are isolated from other tenants. Custom SDK plugins uploaded by one customer run only within that customer's environment and do not affect other customers sharing the platform.
As Hubert mentioned, you add and use SDK extensions the same way as on-premises.

In reply to: Konrad Keppert (WEBCON)

Hi,

Please note that Diagnostic logging mode "Debug" (configured in https://docs.webcon.com/docs/2026R2/Studio/SystemSettings/GlobalParams/ ) *DOES NOT* log to configuration database. It logs to content database, table "AdminDebugLogs".
The amount of logs in BPS_Config.dbo.AdminServiceLogs is related to "Database log level" configured in Services configuration (https://docs.webcon.com/docs/2026R2/Studio/SystemSettings/ServiceConf/ ). Make sure it is not set to Debug or Info.
If the AdminServiceLogs is too big, the supported way of removing data is by scheduling "Database maintenance hours" - see https://docs.webcon.com/docs/2026R2/Studio/SystemSettings/ServiceConf/Schedules/#3-database-maintenance-hours .

However, in emergency situations such as this, I would suggest:
1. copying the content of AdminServiceLogs to another custom table, to not lose logs if they're needed in the future (SELECT INTO AdminServiceLogs_copy or something like that)
2. truncate the original table in BPS_Config database

Thanks, Konrad! Yes, debug logging was enabled in the service configuration settings (I made a mistake when write the question), but that setting was changed to "ImportantInfo" a long time ago. The maintenance plan has run multiple times since then, yet the size of the `AdminServiceLog` table remains unchanged ( it occupies 10 GB). Thanks for the advice! We executed: 1.truncate the table, 2.shrink the `BPS_Config.mdf` file, 3.rebuild indexes and 4.update statistics. Now all work without problem and there are free disk space.