1941年から1949年にかけては朱鞠内駅構内に朱鞠内機関支区が設けられ、C11形蒸気機関車が6両配置されていた。その後は8620形や9600形などの蒸気機関車が列車の牽引を行っており、1970年代まで9600形の牽引する混合列車が残っていた。1955年8月からはキハ10000形レールバスの寒地仕様車（後のキハ01形・キハ02形）が導入され、フリークエンシーの向上が図られたが、時間帯によっては輸送需要に応じきれず、1958年にはキハ05形に置き換えられた。キハ05形では客室内の片隅にベニヤ板で囲われた簡易便所の設置も行われていた。1966年以降は北海道向けに製造されたキハ21形・キハ22形が運用されるようになり、概ね1両から3両で運用されていた。運行形態の節で述べたように、この時期は朱鞠内駅を境にして運行系統は分断されており、深川駅から朱鞠内駅までは深川機関区、名寄駅から朱鞠内駅までは名寄機関区の気動車が運用されていた。1986年以降は旭川運転所のキハ53形500番台が運用されるようになったが、この車両は駆動用エンジンを2基装備した車両であり、冬季でもキハ53形による単行運転が主体となった。夏季にはキハ54形や、駆動用エンジンが1基のキハ40形も運用されることがあった。
幌加内線として深川駅と朱鞠内駅を結ぶ区間が開業したころは、1日4往復の混合列車で、所要時間は3時間程度であった。名寄まで開通して深名線となった時点では、深川駅と名寄駅を結ぶ列車が3往復で、深川駅と朱鞠内駅・名寄駅と朱鞠内駅を結ぶ区間運転の列車が1往復設定されていた。戦後になると1往復が減便となり、全線で3往復となっていた。1955年（昭和30年）8月にはレールバスが導入され、全線を直通する列車は4往復となり、これに加えて区間運転の列車が下り5本・上り7本設定された。翌1956年（昭和31年）11月には区間運転の列車が10往復に増発された。その後、気動車列車に使用する車両はキハ05形に変更された。1962年（昭和37年）7月のダイヤ改正からは、朱鞠内駅を境界として運行系統が分断されるようになった。これは、深名線の沿線が北海道でも有数の豪雪地帯であり、列車のダイヤが乱れても影響を少なくするための方策であった。運行本数がもっとも多かったのはこの時期で、深川駅からは朱鞠内駅までの列車が6往復と鷹泊駅までの列車が上り3本・下り1本、名寄駅からは朱鞠内駅までの列車が5往復と天塩弥生駅までの列車が2往復設定されていた。しかし、利用者の減少などに伴い、1980年（昭和55年）10月のダイヤ改正では、深川駅からは朱鞠内駅までの列車が5往復と鷹泊駅までの列車が上り2本・下り1本、名寄駅からは朱鞠内駅までの列車が4往復に減便された。その後さらに減便され、分割民営化直後の時点では深川駅から幌加内駅までが5往復、幌加内駅から朱鞠内駅までは4往復（列車自体は深川駅から直通）、朱鞠内駅から名寄駅までは3往復となった。国鉄分割民営化後、他の道内の路線（札幌近郊の路線を除く）では普通列車や快速列車において車掌省略のワンマン運転を順次開始していたが、前述したように、深名線についてはワンマン化されることなく営業最終日まで全列車車掌が乗務していた。このため深名線内各駅でのワンマン化対応工事も他の路線が発着する起点、終点の深川駅、名寄駅構内を除き行われなかった。
dBASEの問題の1つとして、これがクライアントサーバモデルに基づいていないという点が挙げられる。つまり、コンピュータネットワーク経由で複数のユーザーがデータベースにアクセスするという使い方ができないのである。データベースをネットワーク上で使うには、データベースファイル全体をPC間で転送する必要があった。クライアントサーバ型のデータベースはdBASEのようなスタンドアロンのシングルユーザ向けシステムとは根本的に異なる。従って、それをクライアントサーバ型に作り直すのは大変な作業となってしまう。しかしながらネットワークが企業で当たり前に使われるようになってきたため、アシュトンテイトの製品はその環境にはそぐわなくなってきていた。dBASEの開発者だったラトリフはエスバーとの確執から既に退社しており、クライアントサーバモデル対応の次世代dBASEの開発ではロングが主任アーキテクトとなった。一方でエスバーはMicrosoft SQL ServerをdBASEのバックエンドとする（逆に言えば、dBASEをMicrosoft SQL Serverのフロントエンドにする）という構想をぶち上げ、マイクロソフトのビル・ゲイツと共同で記者会見を開いている。これが実現すれば、既存の dBASE 利用者がその資産を生かしつつクライアントサーバ環境に移行できるということになる。アシュトンテイトは1986年のdBASE新バージョンの出荷を予定し、公表していた。この新バージョンは性能や機能が強化され、Microsoft SQL Serverとの親和性を高めるためにSQLもサポートし、コンパイラも内蔵する予定だった。しかし、新バージョンのリリースはプロジェクト管理の失敗により1988年10月にまで遅延した。その結果リリースされたdBASE IVも性能が悪く、バグが多かった。dBASE IVの開発はdBASE IIIのコードが基本となっていたが、そのコードは移植に次ぐ移植でいわゆる「スパゲッティコード」になっていて、ある箇所のバグを潰しても別の箇所に影響が出るといった具合で修正は困難を極めた。もっとも修正版を素早くリリースすれば大きな問題とはならないし、実際dBASE IIIのときもアシュトンテイトは同様の状況を乗り切っていた。しかし、dBASE IVにまで至ると余りに仕様変更やバージョンアップすべき箇所・加えてデバッグの必要がある箇所が多くなり過ぎて、状況は最悪となった。しかも、dBASE IVには予定されていたコンパイラ機能が無く、実際に使ってみると何時も間違った答を返し、頻繁にクラッシュしてはデータベースファイルを破壊した。適切なアップデートを行おうにも困難を極め、改良版のdBASE IV 1.1がリリースされたのは実に2年も経った後・エスバーが経営陣から追われた後であった。結局、その間に多くのユーザーがFoxBaseやClipperなどのdBASEクローンを使うようになり、dBASEのシェアも1988年にはPC用データベース市場の 63%を占めていたのが翌1989年には43%にまで急落した。また、Microsoft SQL Serverとの連携もうまく行かず、マイクロソフトは代替のフロントエンドとしてMicrosoft AccessをリリースすることになりdBASEはますます旗色が悪くなった。