Mssql Bundle Laravel Package

Product Decisions This Supports

• Enterprise/legacy integration feasibility. If a paying customer, partner, or internal system-of-record runs Microsoft SQL Server, this package is a low-cost way to answer "can we integrate, and how long would it take?" before committing roadmap capacity. It makes the *nix case (FreeTDS/dblib) viable, which is usually the blocking question when the app fleet is Linux containers.
• Build vs. buy for the connector layer. The package wraps a narrow but genuinely fiddly concern — UTF-8 round-tripping over dblib and transaction/savepoint behavior that Doctrine's stock driver path handles inconsistently. The decision it informs is: do we vendor a thin bundle, fork it, or spend 1–2 sprints writing and testing our own connection/type-mapping layer? At ~16 stars and 0 dependents, "buy" here really means "adopt and own," so price it as a fork, not a dependency.
• Data-integrity risk on the roadmap. UTF-8 corruption on non-ASCII data (customer names, addresses, product descriptions in European/Asian markets) is a silent, high-severity defect class. Adopting a package that states UTF-8 support explicitly lets you close that risk item without a custom test harness — or, if you decline it, tells you to budget for that harness.
• Platform standardization. Supports whether one codebase can serve both Windows (sqlsrv) and Linux (dblib) deployments. That shapes CI matrix scope, container base images, and ops runbooks — decisions that are cheap now and expensive after a release.
• Deal qualification / scoping accuracy. For pre-sales or discovery, a working connector sample de-risks estimates on SQL Server-flavored engagements far more than a spike done from scratch.

When to Consider This Package

Adopt or evaluate when all of the following hold:

• The application is Symfony, on a Doctrine DBAL stack, and you need SQL Server as a first-class connection rather than an afterthought. This is not a Laravel package — despite being PHP and Composer-installable, it registers a Symfony bundle and expects Symfony's DI/config conventions. In Laravel you should use the framework's own sqlsrv/dblib driver support or a Laravel-specific connector; porting this bundle into Laravel means unwinding the bundle wiring, which is real work for a thin payoff.
• You deploy on Linux/*nix and must reach SQL Server via dblib/FreeTDS — the path where driver-level UTF-8 handling and transaction semantics are weakest and where this package's stated value is highest.
• You need UTF-8 correctness or explicit transaction control (nested transactions, savepoints, rollback behavior) as a hard requirement, not a nice-to-have.
• You have the appetite to pin a version and own a fork. With 0 dependents and a small star count, treat it as reference implementation and source of truth for the config, not as a maintained upstream you can rely on for security patches.
• The SQL Server instance is legacy enough that modern Linux-native SQL Server or pdo_sqlsrv-on-Linux isn't an option.

Look elsewhere when:

• The stack is Laravel, or framework-agnostic PHP — the bundle abstraction is dead weight and you'll fight it.
• The estate is SQL Server 2017+ on Linux with pdo_sqlsrv available; Doctrine DBAL's first-party drivers plus a UTF-8 collation/encoding config likely covers you with no third-party surface.
• You require active maintenance, a CVE response process, or commercial support — none of that is on offer at this maturity level.
• You're planning a multi-tenant or high-throughput data path where you need benchmarked, profiled driver behavior; a 16-star package won't have that evidence and you'd be the one producing it.
• A greenfield build where you can choose PostgreSQL or a modern SQL Server setup instead of accommodating a legacy one.

Recommendation on the score (0.24): treat as viable spike, not viable dependency. Timebox a one-day evaluation against a real schema, and if it earns its place, fork it into your org namespace with tests and a named owner.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a recurring requirement to read and write data in customer-owned Microsoft SQL Server systems, which today is an unscoped risk on our roadmap — especially for non-English data, where naive connectors silently corrupt characters, and for Linux deployments, where the driver story is weak. An open-source MIT-licensed PHP connector exists that targets exactly those two problems. It is small and lightly maintained, so the proposal is not to depend on it as-is, but to use it as a vetted starting point: a short evaluation now, and if it holds up, a fork we own. Cost is roughly one engineer-day to evaluate and a small, bounded maintenance line item thereafter. The alternative — building and testing this ourselves — is one to two sprints. The decision requested is approval for the evaluation and a standing owner for the fork if we proceed.

For engineering (one paragraph): mediamonks/mssql-bundle is a Symfony bundle wiring Doctrine DBAL to SQL Server on Windows (sqlsrv) and *nix (dblib/FreeTDS), with explicit UTF-8 conversion and transaction support — the two areas where the stock driver path bites. Scope of value is narrow: connection configuration, encoding, and transaction semantics. Scope of risk is maintenance: 16 stars, zero dependents, no visible support commitment. Plan accordingly — vendor or fork rather than float on dev-main, add our own contract tests covering non-ASCII round-trips and rollback/nested-transaction behavior, and confirm it isn't redundant with DBAL's pdo_sqlsrv driver if the target instance runs modern SQL Server on Linux. Also confirm framework fit: this is Symfony-only, so it does not transfer to our Laravel services.