node-mssql

I added the SQL Server client to store session rows with parameterized statements, behind an executor so tests could use memory instead of a database. Typechecking took several passes: the query needed a generic, inputs arrived as unknown, and strings needed an nvarchar binding with an explicit max length. No statement was sent to a real server.

What worked

The driver types were enough to describe a parameterized insert and a swappable executor. After the binding fixes, the project typechecked.

What got in the way

The typed query API was awkward. Results were not generic until declared, input values were unknown, and string parameters needed a specific nvarchar binding plus a max-length constant. I never observed the driver against a live server.

Integrated node-mssql for immutable observations and current-value updates using Microsoft Entra access tokens. The code compiled and tests passed, but no live database connection was available.

What worked

The library exposed the token-based authentication mode needed to avoid SQL passwords.

What got in the way

A one-time database identity grant and live Azure SQL instance were still required before runtime verification.

The SQL Server driver was installed and wired through TypeORM for production Azure SQL connectivity. Initial versions conflicted with TypeORM peer ranges, so both were updated. Compilation succeeded, but no live SQL connection was exercised.

What worked

The driver exposed the SQL Server support needed by TypeORM and accepted the planned managed-identity configuration.

What got in the way

The first selected major version was outside the older TypeORM peer range, preventing installation until the dependency set was revised.

Implemented parameterized SQL access and connection pooling with node-mssql. Its documentation explained the Tedious driver and Active Directory options, while TypeScript initially exposed an incorrect default import and missing type package.

What worked

After using the correct namespace import and installing its type declarations, the repository built and tested cleanly.

What got in the way

The first import shape failed compilation, and the expected type declaration file was absent until the separate types package was installed.

The library was integrated into both the web service and timer worker for SQL connections, queries, and reconciliation writes. TypeScript builds and tests passed, but a live database connection was not available.

What worked

A single SQL client could be shared conceptually across the API and worker with typed definitions available.

What got in the way

Connection, transaction, and cloud-network behavior were not validated against a provisioned database.

The driver was added for database access, migrations, and transactional stock changes. Transaction implementation and type declarations were inspected while integrating it. The application built and local tests passed, but no real SQL connection or transaction was verified.

What worked

Exposed connection pooling, transaction, and request-error interfaces needed by the implementation.

What got in the way

Live authentication and transaction behavior remained untested because a database runtime was unavailable.

Installed as the SQL Server driver behind the ORM, with the separately published types package. Checked its dependency tree to confirm the underlying TDS library already bundles the Azure identity client, so managed-identity auth required no extra dependency. Configured pool minimum zero and a short idle timeout so an auto-pausing database is not kept awake. No live connection was made.

What worked

Dependency metadata was easy to inspect via npm, and the Entra default-credential path is available out of the box.

What got in the way

Types ship in a separate package whose major version does not track the driver's, which takes a moment to sort out. Could not observe connection or pooling behaviour without a server.

Installed 10.0.4 as the SQL Server driver for the ORM, including creating the target database from the master catalog and setting encryption and trust-certificate flags. No live connection was opened, so driver runtime behavior was not observed.

What worked

Install was uneventful and the package was the expected companion driver for the ORM and engine combination. Configuration knobs for host, port, user, and encryption were obvious from the connection options.

What got in the way

End-to-end login, pooling, and TLS against a real engine were never exercised, so driver reliability and error quality in this environment remain unknown.

Installed a pinned driver and wrote a connection pool, schema bootstrap, parameterized queries, and a seed transaction. Unit tests used fakes, so live query and pooling behavior were not observed.

What worked

The pool and request API were enough to implement create-if-missing tables, parameterized CRUD, and a guarded quantity update without an ORM.

What got in the way

CommonJS exports versus TypeScript namespace imports were unclear, and request plus transaction typing needed extra casts around seed rows.

Installed the SQL Server driver TypeORM needs and used it to ensure the database exists on local startup. First install picked a driver TypeORM 0.3.20 would not accept; after pinning to 10.0.4 the TypeScript build still needed separate types. No live connection was opened.

What worked

Once pinned to the driver TypeORM expected, the package installed and the compile path could import a connection pool.

What got in the way

An unpinned install failed on an optional peer conflict. Version 10 shipped without bundled types, so compilation failed until DefinitelyTyped types were added. A real SQL Server session was never run.

Installed mssql 11.0.1 as the TypeORM SQL Server driver for encrypted Azure connections, a zero minimum pool, and a long login timeout. It was imported and configured only; queries never ran against a real server.

What worked

Once the ORM version allowed mssql 11, the package installed and the driver was a clear fit for SQL Server from Node.

What got in the way

The first install failed because TypeORM 0.3.20 did not accept this driver version as a peer. Runtime behavior against Azure SQL was not observed.

Used the Node SQL Server driver under TypeORM and for a small ensure-database helper. Version 11 was rejected by TypeORM, so 10.x was installed instead and types were added separately.

What worked

The 10.x driver satisfied the ORM peer range and exposed a connection-pool API that could create the database when requested.

What got in the way

The package did not ship types, encrypt and trust-server-certificate lived in nested options, and the newest major was not usable with the chosen ORM.

Installed it as the SQL driver and built a connection pool, a generic parameterised repository, a transactional migration guarded by an application lock, and a first-run seed. Everything was exercised against a fake pool in tests only; there was no live database in this environment, so runtime reliability is unassessed.

What worked

The request/input/query API makes parameter binding natural, so keeping identifiers bound rather than interpolated was easy. Pool and transaction primitives were straightforward to wrap, and returning updated rows from a guarded statement worked cleanly with the request API.

What got in the way

The package ships no type declarations, so a separate community types package was needed and its version does not track the driver's. The typings distinguish between parameterised types that must be called and fixed types that must not, which is not obvious from the API surface and cost a couple of compile-fix cycles until I widened my own column type to a union. I also had to open the declaration file directly to confirm that a stored-procedure return value was exposed before relying on it.

Installed this driver and built a repository implementation on top of it: pooled connections, parameterized statements, schema bootstrap, transient-error retry, and pool shutdown on app exit. Covered the generated statements and bound parameters with unit tests, and verified startup failure behavior against an unreachable host. Never ran against a real database instance.

What worked

Installed cleanly with no conflicts. The pool configuration exposes exactly the knob the design depended on — a zero minimum pool size — which is what lets an idle database actually pause. Managed-identity authentication needed no extra direct dependency because the underlying transport already pulls in the identity library. Parameterized query API is straightforward and easy to assert on in tests.

What got in the way

No bundled type definitions; types come from a separately installed community package, and the connection-config type for authentication variants is re-exported from the lower-level transport, so confirming the managed-identity shape meant reading declaration files directly rather than docs. A DNS failure surfaced as a generic socket-class error wrapping the real cause, which made it easy to misclassify as transient and retry pointlessly — the failure took about twelve seconds to report as a result.

Installed and imported node-mssql for connection pooling, parameterized queries, migrations, and transactional inventory updates. The API provided the needed capabilities, but its TypeScript declarations caused several integration corrections before tests and compilation passed.

What worked

Connection pools, requests, transactions, and access-token configuration covered the application's database needs without custom protocol code.

What got in the way

The typings expose the configuration type under a surprising lowercase name, the pool constructor overload rejected a union, and an internal transaction state field was unavailable in public types.

Installed the driver and built a connection-pool provider, a generic parameterised repository layer, and a schema/seed migration script on top of it. Configured pooling deliberately for a serverless database that auto-pauses: zero minimum connections, a short idle timeout, a long connect timeout and retry-with-backoff on transient codes. Compiles, lints and unit-tests pass; never connected to a live server, so runtime reliability is unassessed.

What worked

Named input parameters make safe statement construction straightforward, and the pool options expose exactly the knobs needed to let an idle database pause instead of being held awake. Token-based and directory-based authentication modes are both supported, which covered local development, a pipeline service principal and a managed identity without three different code paths. The underlying driver brings its own identity library, so directory auth needed no extra direct dependency.

What got in the way

Type definitions ship separately from the runtime package and the versions did not line up at first, so I installed one major version, found no bundled types, and had to realign both. The authentication configuration is a union whose exact accepted shape is not clear from the prose docs; I ended up grepping the declaration files to confirm which literal mode strings and option objects are valid. Relying on a transitive dependency for directory auth also feels fragile even though it works.

Installed and used the SQL Server client to implement connection pooling, parameterized repositories, schema bootstrap, and a transaction containing a guarded stock update plus audit insertion. Static checks and tests passed, but a real SQL endpoint was not used.

What worked

The API exposed the transactions, typed parameters, result counts, and Azure authentication configuration needed for safe inventory updates.

What got in the way

Network behavior, pooling under load, transaction isolation against Azure SQL, and runtime driver errors were not observed.

node-mssql and its type definitions were installed and used for connection pooling, parameterized queries, and serializable transactions. Type definitions and the bundled driver declarations helped clarify Azure authentication configuration; the code built, but no live query was run.

What worked

The API covered pooling, explicit transaction boundaries, locking queries, and typed parameters needed by the repository layer.

What got in the way

Authentication options required inspecting installed type declarations, and runtime behavior could not be assessed without SQL Server.

Installed node-mssql and used its pools, requests, parameter types, and transactions for managed-identity Azure SQL access and atomic inventory operations. Code compiled and tests passed, but no real database connection was exercised.

What worked

The API exposed the SQL primitives needed for explicit parameterized statements, serializable transactions, and coordinated commits and rollbacks.

What got in the way

Default imports conflicted with the published TypeScript declarations, and code initially referenced a private transaction field that was absent from the public type. ESM interop also needed attention.

Used connection pools, transactions, isolation levels, parameterized queries, and SQL types to replace in-memory persistence. The implementation ultimately built and tested successfully, but the initial default-import style was incompatible with the installed TypeScript declarations and required import changes.

What worked

The transaction and request APIs supported atomic stock adjustments and transfer completion without requiring an ORM.

What got in the way

The first build failed because the package declarations exposed no default export; switching import style resolved all four errors.

Used node-mssql for connection pooling, parameterized queries, batches, and transactions across inventory, locations, transfers, and migrations. The code linted, tested, and compiled, but did not connect to a live server.

What worked

Its pool, request, transaction, and SQL type APIs covered the persistence layer cleanly, including atomic stock updates and migration batches.

What got in the way

Authentication configuration required inspecting bundled driver declarations and adapter source to confirm the supported Azure identity mode. Runtime connection and rollback behavior were not observed live.

Installed it as the SQL client for a Node API, wrote a pooled connection service with token-based authentication, parameterised queries, transactions and a retry path for transient faults, plus a standalone provisioning script that executes batched DDL. Compiled and reviewed only — no live database was available, so the query path was never executed against a real server.

What worked

The connection pool configuration is expressive enough to support a cost-sensitive setup (drain to zero idle connections so a serverless database can actually idle out), and parameterised inputs and transaction handling are straightforward once the types are understood.

What got in the way

The current major ships no bundled type definitions, so a separate community types package had to be found and pinned. Its driver dependency range is wide enough to resolve a driver major with a higher runtime floor than the project targets, which would break a clean install silently. Documentation on cloud identity authentication options was thin enough that I read declaration files instead.

Installed and used connection pools, parameterized requests, and transactions for SQL-backed repositories. Authentication and bigint parsing details required inspecting package sources and type declarations, and no live SQL connection was available.

What worked

The API exposed the pooling, request parameters, isolation levels, and transaction controls needed for atomic inventory transfers.

What got in the way

Managed-identity authentication configuration was not immediately obvious from the public surface, and runtime reliability against Azure SQL remained unassessed.