Hi,
The "Network Error" with no detail when you cross 326 selected columns on a wide SQL Server table is a known limit of the SQL Server connector, not a Power Apps Form bug — and the reason it changed last Thursday is almost certainly an on-premises data gateway update tightening enforcement. Here's what Microsoft documents and what to do.
Why there is a "column limit" at all
It isn't a column count limit per se — it's a serialized row payload size limit on the SQL Server connector. Every row returned by the connector is serialized to JSON and sent through the gateway, and the connector enforces a request/response size cap per call. With ~370 columns the row easily crosses that cap, and the connector returns a generic network error because the serializer aborts before a real SQL error is generated. The "326 works / 326+1 fails" boundary is whichever column types you add first happen to push the JSON over the cap.
Why it suddenly stopped last Thursday
The on-premises data gateway service ships monthly updates and clients in the supported window are auto-rolled forward. Updates frequently tighten payload, timeout, and serialization enforcement — apps that were squeaking under the previous threshold start failing after the rollup. There's nothing wrong with your app design; the runtime got stricter.
What to do — in order of effort
- Stop pulling every column into the Form. A Form control returns whatever DataSource returns; if you can't change the column list there, replace the Form's DataSource with a projection. Two supported ways:
- Create a SQL view on the table that selects only the columns the Form actually displays/edits, and bind the Form to that view instead of the base table. Views appear as data sources in Power Apps. Reference: Use SQL views with Power Apps.
- Use
ShowColumns() on the Form's DataSource expression to project down: Form1.DataSource = ShowColumns(MyTable, "Id", "ColA", "ColB", …). Reference: ShowColumns, DropColumns, AddColumns, RenameColumns.
- If you genuinely need all 370 columns in one screen, split the data across multiple Forms (each bound to a narrower view) on tabs or sections, and write back through stored procedures rather than a single Form.SubmitForm() round-trip. The SQL connector's Execute stored procedure action avoids the wide-row serialization on submit. Reference: Execute SQL stored procedure.
- Confirm the gateway version on the host machine. If it's the latest and rolling back isn't an option (Microsoft supports only the current and previous releases), the projection in step 1 is the durable fix — the cap won't move back.
- Long-term: tables with hundreds of columns are usually a sign the row should be normalized or moved into Dataverse, which Power Apps treats as a first-class store without the connector serialization cap. Reference: What is Microsoft Dataverse?.
Quick diagnostic
If you want to confirm it's payload size rather than something else, open App checker → Monitor in Power Apps Studio while the Form is loaded, trigger the lookup, and look at the SQL request's response size and status. A connector-level abort shows as a 4xx/5xx with no SQL exception body — that's the serialization cap signature. Monitor docs: Monitor your apps in Power Apps.
Net: the "Network Error" is the SQL connector aborting an oversized serialized row; the timing matches a gateway monthly update tightening enforcement; the supported fix is to project to only the columns the Form needs (view or ShowColumns). The 326-column boundary is a payload-size artifact, not an intentional product limit.
Found this helpful? Please mark ✅ "Does this answer your question?" so others searching for the same issue can find it quickly. A 👍 on "Was this reply helpful?" or a ♥ Like is also much appreciated!
Raghav Mishra — LinkedIn | PowerAI Labs
