Hello,
Thank you very much for the detailed explanation.
Using the options input with a custom windowClass and applying the width override in global styles resolved the issue perfectly. We can now control the width of a single <abp-modal> without affecting other modals, exactly as needed.
Really appreciate the clear guidance and references provided.
Best regards,
Hello, I need assistance with a multi-tenant issue that I can no longer resolve.
I reverted all recent changes and restored the project to the exact state it had when tenant-specific databases were working correctly. However, even after fully rolling back everything, the system still does not use the tenant databases.
The behavior is the following:
The system successfully creates the database for each tenant when the connection string is defined.
The connection strings appear correctly in the tables SaasTenants and SaasTenantConnectionStrings, including a valid “Default” entry for each tenant.
All entities implement IMultiTenant, and no DbContext contains hard-coded connection strings.
Despite this, ABP always writes and reads data from the Host database, completely ignoring the tenant’s “Default” connection string.
Tenant databases remain empty because they are never used.
This issue persists even after restoring the project to the original version where everything previously worked.
No matter which tenant I log in as, EF Core operations (insert/update/select) still target the Host DB.
In short:
ABP creates the tenant databases, but the application never switches to them — all data continues going to the Host DB even after reverting every change.
I would appreciate guidance on what could cause ABP to stop switching the connection string per tenant, even after a full rollback.
The ABP application host cannot reach the remote SQL Server because the required TCP port is not open / reachable.
This explains the behavior:
Using localhost works → The API host can reach the SQL instance immediately.
Using the remote connection string fails → ABP rejects the string as “invalid” because the host cannot establish a TCP connection to the SQL server.
It does not depend on permissions → I can save other connection strings (e.g., localhost) in the same session with the same user.
The PUT endpoint only fails for the remote connection → The same user, same role, same claims, same token can save local DBs successfully.
The error appears ONLY when the SQL server is remote → This confirms that the network path, not ABP permissions, is blocking the connection.
So, the 403 response from:
PUT /api/saas/tenants/{id}/connection-strings
is triggered because ABP internally considers the connection string invalid, due to the SQL host being unreachable from the application server (port closed, SQL Browser unreachable, or firewall blocking).
Once the required SQL port is opened and reachable, the connection string should save correctly.
Thank you, everything is working correctly now.
One more question: Where can I find the backend logs generated by ABP? I would like to inspect runtime errors coming from the HttpApi.Host and the application layer.
Thank you — the checklist you provided resolved my issue for now. Running the DbMigrator first and aligning all connection strings fixed the inconsistent initialization and the missing admin/client records.
I have one additional question:
How should I properly regenerate the client-side proxies after creating a new application service?
In previous ABP versions I used commands like:
abp generate-proxy
or (for Angular)
abp generate-proxy -t ng
But I want to confirm the correct and recommended way in the current framework version, especially when using Angular + HttpApi.Host.
Thanks again for your help — your previous guidance was very useful.
