Files
Fuchs_Intranet/Fuchs_DataService/Fuchs_DataService.xml
T
Stefan c741535aec
Playwright Tests / test (push) Canceled after 0s
feat: Implement mfr truncation fix and enhance invoice handling
- Added a new SQL script to address the "String or binary data would be truncated" error in mfr sync by widening the Note fields in service objects and companies to NVARCHAR(MAX).
- Updated the table types and associated stored procedures to accommodate the changes, ensuring compatibility with existing data.
- Queued a re-sync for previously rejected rows due to truncation issues.
- Created application logins for fuchs_fds and fuchs_web with placeholder passwords for initial setup.
- Introduced functions for invoice backdating and invoice date retrieval to streamline invoice processing.
- Developed a password generation function with customizable parameters for length and character types.
- Added a random number generation function to support password creation.
2026-09-30 16:56:08 +02:00

102 lines
6.7 KiB
XML

<?xml version="1.0"?>
<doc>
<assembly>
<name>Fuchs_DataService</name>
</assembly>
<members>
<member name="T:fds.FdsColumnWidths">
<summary>
Explains an mfr merge that failed with "String or binary data would be truncated": SQL Server
(message 8152, or 2628 below compatibility level 150 / without VERBOSE_TRUNCATION_WARNINGS)
does not name the column, and the merge proc copies the staging table into both the
<c>mfr__tt__*</c> table type and the <c>mfr__*</c> target. After such a failure the staged
<see cref="T:System.Data.DataTable"/> is compared against the narrower of the two declared widths, so the
error log names the column, the longest value and an entity Id.
Runs only on the failure path — no cost for a successful merge.
</summary>
</member>
<member name="T:fds.FdsColumnWidths.Overflow">
<summary>One column whose staged values exceed the declared width.</summary>
</member>
<member name="M:fds.FdsColumnWidths.Overflow.#ctor(System.String,System.Int32,System.Int32,System.Int32,System.Object)">
<summary>One column whose staged values exceed the declared width.</summary>
</member>
<member name="M:fds.FdsColumnWidths.IsTruncationError(System.Int32)">
<summary>8152 = classic truncation message; 2628 = verbose variant (compat level 150+).</summary>
</member>
<member name="F:fds.FdsColumnWidths.WidthsSql">
<summary>
Char width of every bounded string column of the target table and of its
<c>mfr__tt__</c> table type (same naming rule as the <c>mfr__updt__</c> merge proc);
where both declare the column the narrower wins. MAX columns (max_length = -1) are omitted.
Expects parameter <c>@tablename</c>.
</summary>
</member>
<member name="M:fds.FdsColumnWidths.ToWidthMap(System.Data.DataTable)">
<summary>Rows of <see cref="F:fds.FdsColumnWidths.WidthsSql"/> → column name → max chars (case-insensitive).</summary>
</member>
<member name="M:fds.FdsColumnWidths.FindOverflows(System.Data.DataTable,System.Collections.Generic.IReadOnlyDictionary{System.String,System.Int32})">
<summary>
String columns of <paramref name="batch"/> holding at least one value longer than the
declared width, one entry per column with the longest value's length and row Id.
Columns without a known width (MAX or not declared) are never reported.
</summary>
</member>
<member name="M:fds.FdsColumnWidths.Describe(System.Collections.Generic.IReadOnlyList{fds.FdsColumnWidths.Overflow})">
<summary>Log-friendly summary; "none detected" when the batch fits the declared widths.</summary>
</member>
<member name="T:fds.FdsSqlOptions">
<summary>
Logs every SQL error through the worker's structured <see cref="T:Microsoft.Extensions.Logging.ILogger"/> alone — which, when
this worker runs hosted inside the Fuchs web app (ADR 0010), also reaches the OCORE MultiLogger
SQL sink at Warning+ (ADR 0024) and lands in the same <c>fds__debuglog</c> table
<c>FdsDebug.DebugLog</c> used to write to directly. Calling both here would double-write
every row, which is exactly what the original 2026-09-16 log review's back-to-back
"mfr__getSchema"/"fds__getUpdateableRequests" deadlock entries were heading towards once the
SQL sink went live — so this class no longer calls <c>FdsDebug.DebugLog</c>. Passing a
<c>logger</c> is optional; falls back to the static <see cref="F:OCORE.Logging.Logger"/>
(set once in <c>Program.cs</c>) so a failing stored procedure is never silently dropped.
<c>FdsDebug.DebugLog</c> remains the primary/only DB-attribution path for every other
call site in this project that doesn't separately log through <see cref="T:Microsoft.Extensions.Logging.ILogger"/> — it was
deliberately not migrated onto the generic pipeline (see ADR 0024's Consequences).
</summary>
</member>
<member name="F:fds.FdsMfr.InvoiceFileDownloadConcurrency">
<summary>Max parallel invoice-file downloads (independent per file).</summary>
</member>
<member name="M:fds.FdsMfrClient.DatabaseSchema.ShapeTableNames(System.String,System.Data.DataRowCollection)">
<summary>
Entity table plus its navigation tables, without blanks: the list of tables whose
(empty) shape is loaded. Empty when the entity table itself is unknown.
</summary>
</member>
<member name="M:fds.FdsMfrClient.DescribeOverlongColumnsAsync(System.Data.DataTable)">
<summary>
Failure path only: names the staged columns wider than the target table / table type allow.
Never throws — a failed lookup is reported in the returned text instead.
</summary>
</member>
<member name="T:fds.FdsConfig">
<summary>
Holds the application <see cref="T:Microsoft.Extensions.Configuration.IConfiguration"/> supplied by the host (the Fuchs web app).
Fuchs_DataService is a library — it has no configuration of its own; the host owns the
connection strings and MFR credentials and injects them via <see cref="M:fds.FdsConfig.Initialize(Microsoft.Extensions.Configuration.IConfiguration)"/>,
which <c>Program.cs</c> calls once at startup before any <see cref="T:fds.FdsMfr"/> use.
</summary>
</member>
<member name="T:fds.FdsDocumentNames">
<summary>
Download-filename sanitising shared by every path that hands a document to the browser —
stored documents (<see cref="M:fds.FdsMfr.GetReportDoc(System.Byte[]@,System.String,System.Boolean)"/>) and documents regenerated on a miss
(<c>IntranetController.HandleReportDoc</c>, ADR 0025) — so both produce the same name for the
same DocumentName. DocumentName is derived from the user-typed invoice title, so it can carry
path separators ("Wartung 2025/26"), stray editor markup and characters Windows rejects.
</summary>
</member>
<member name="M:fds.FdsDocumentNames.SafeFileName(System.String,System.String)">
<param name="documentName">Raw DocumentName (may be null, empty, or wrapped in &lt;p&gt;).</param>
<param name="fallback">Used when nothing usable remains after cleanup.</param>
</member>
</members>
</doc>