Help Architecting MSWord as Access Front (1 Viewer)

AvantGuy

neophyte
Local time
Today, 06:01
Joined
Mar 25, 2018
Messages
22
My first post here; I'm nothing close to a seasoned MSOffice developer. Since this application doesn't seem unusual, I figured there are use-cases out there, but I couldn't find anything that seemed close enough. I titled this "MSWord as Access Front-end" but that might be mischaracterizing, as you'll soon be able to advise me.

First the big questions to offer an initial sense of who wants to tackle this for me, then followed by the detailed description:

  1. Will some dialogs be presented by Access VBA, and some by Word VBA?
  2. Do free-text fields present an issue in Access?
  3. Should I conceive this as solely an Access-controlled series of data-entry forms and then as a final step, through the use of some kind of Word template, have Access populate and generate that Word doc through OLE or DDE interprocess automation of Word?
  4. If so, would that only work with a local instance of Access?
  5. If the database could be remoted, would it require SharePoint?
  6. If so, would Access handle it? Would it require SQL Server?
  7. Is this a kind of application practicable online in a browser?
  8. Is this app suitable only to the so-called split database approach?
  9. Ideally the legacy doc at his elbow, so to speak, would be updated in near realtime as the dialogs pop and he navigates through them. Is that practical in a remote database scenario, or, even a local db scenario?
My client has been using a dense Word doc as a reporting mechanism, with a variety of controls with things like multiple strings of checkboxes, dates, a few free text fields, and text colorations depending on the value of a flag field. There are a couple Word doc tables whose number of rows will change based on the value of a another flag field in the site's Access dataset.

There could be a dozen Word docs per unit, multiple units per site, multiple sites per customer, and of course multiple customers. Clearly a relational database challenge that he's been trying to handle with gazillions of freestanding Word docs. There are about 70 customers, so we're hoping Access is still viable, although I wonder about the free-text data viz-a-viz Access.

My design objective requires retention of his current Word doc as the reporting/for-print mechanism, but gets him away from using it for data entry. Its ultimate role will be for printing reports only, but secondarily also as a backup data entry mechanism.

I'm conceiving of dialogs with user forms/content controls that he'd step through, not only field-by-field but unit-unit, site-site, etc. An initialized dialog form (if new customer, new site, new unit) or pre-populated dialog form would present itself when he wishes to be in sequential data-entry mode, the default. The master dialog must begin with a directory (and/or a search field) via which he could select a single customer, or down the hierarchy, a specific site or unit, etc. The final printed result is dictated by the legacy Word doc, which can be updated to use the latest content-controls if necessary.

In the initial unit dialog, some fields, fixed-length text and particularly dates (eg, of next scheduled service) would be calculated and automatically update the appropriate field of the current dataset (in the doc's datastore, or purely Access?) AND any relevant controls in a dialog not yet but soon-to-be-opened (eg., the next unit in the site's collection of units, etc). Don't think there'd be any caching available (correct?), so we'd hit the database for upcoming site names and master datasets as he pages through. My impression is that the conventional way to get entire Word docs like his legacy form into existence is an Access VBA that would create it all at once as a distinct VBA routine. True? Reasonable alternatives, or would latency kill us in the case of remoting the database?

Other considerations:

* Database sharing via the cloud: By sharing, I don't mean simultaneous accessing by multiple users. I mean rotating users; rotations at a frequency of every few days or a week, but user workstations not necessarily on the same local net. Then there's dba-type maintenance by another person: me, also not ultimately on their local net. This is not an immediate requirement, but is being considered for a full deployment milestone (we could begin operating from a local instance of Access, a single workstation).

(I've a reputation for being long-winded -- hope this seems concise)

Thanks much in advance, Bob
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 07:01
Joined
Feb 28, 2001
Messages
26,996
You have some issues to consider, I'll give you that. Pardon me if I seem to cherry-pick this but basically, some of this is irrelevant to the kind of advice I need to give you.

IN THEORY, you can run VBA behind Word - but it is easier to run it behind Access and use Access automation methods on Application Objects (such as Word) to generate what you want to see in a particular Office-member format.

Should I conceive this as solely an Access-controlled series of data-entry forms and then as a final step, through the use of some kind of Word template, have Access populate and generate that Word doc through OLE or DDE interprocess automation of Word?

I surely do not speak for the community, but this is perhaps easier as an approach than to drive from Word as the starting point.

Will some dialogs be presented by Access VBA, and some by Word VBA?

Probably better to keep all control in Access.

Do free-text fields present an issue in Access?

Clarify your definition of free-text.

When you start talking about web-based and cloud-resident, you start to walk away from Access and start to walk towards web tools. Access really DOES NOT LIKE (let's even say VIOLENTLY DISLIKES) environments in which the shared parts are NOT connected via hard-wired circuitry. Access likes Ethernet backbones. Using wi-fi or any other networking technology that exhibits unstable connections will kill Access databases. Any intermittancy is disruptive if you are lucky and destructive if not so lucky. Remember that Access is a SMALL BUSINESS tool, not one of the "big-boy" databases.

Note also that some versions of Access supported a web-like interface but Access-Web is now a declining feature because it had issues. I'll leave THAT discussion to others, but I'll flat-out tell you, don't design anything new using Access Web even if you have a version of Access that seems to support it. Future versions won't.

Most of what you describe would best be handled in Access simply because it is easier to tie specific controls to specific code.

I'm going to give you two "rules" that I hand out sometimes. I call them the "Old Programmer's Rules" because I am an old programmer. My first computer programs were written in 1968.

OPR #1 - If you can't do it on paper, you can't do it in Access. (And you can extend that in this case to any other Office utility AND any web-based utility.)

What this means in practical terms is that you must design the ... heck ... out of your project. You need to know inside and out what your app will do under any reasonable (and some unreasonable) circumstances. You need plans or a "road-map" to help you decide where you are going. Which leads to the rhetorical question: If you don't know where you are going, how will you ever know you got there?

OPR #2: Access can't tell you anything you didn't tell it first, or at least tell it how to determine what to tell you.

Access is dumber than a box of rusted garden tools. YOU are the subject matter expert so YOU will have to tell it how to do any computations, lookups, etc. As a practical part of this rule, your issue is that (from rule #1) you should have a complete list of what you expect to see in terms out outputs as well as intermediate dialogs and the like. You need to verify that your app has a way to KNOW those desired outputs.

Sometimes, getting the desired outputs is a matter of remembering to ask the right questions to GET that input. I.e. if you want to know X, sometimes the best thing to do is to ask "What is X?" Other times, you want something that only can be found via a formula based on some inputs. In which case you break this part down and verify that the inputs are available AND your app knows the formula to convert the inputs into your desired result.

Which SOMETIMES means that you might need to work backwards to assure that your inputs completely "condone" your outputs.

If you don't do the design work up front including assurance of crucial data availability, you are - to be blunt about it - screwed. Particularly with a project such as the one you just described.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 08:01
Joined
Feb 19, 2002
Messages
42,970
Since you are not an Access developer, this will be a challenge for you but there are a couple of things you need to understand before you commit to a too.'
1. Access is RAD (Rapid Application Development) tool. It creates applications that a user who has no technical knowledge can interact with. it is NOT a database engine. Access is closely associated with the desktop database engines Jet (.mdb) and ACE (.accdb) and so confusion reigns. If you wanted to control everything using Word (I would not recommend this), you could use ACE as your database engine. You would NOT be using Access and you would not even have to have Access installed.
2. Access will be an excellent tool for this project provided you do not have requirements to interact with the application over the web. As Doc already mentioned. Access Web Apps have been deprecated and so even if you are running an old version of SharePoint, you shouldn't even consider this as an option. Besides, AWA never supported VBA so they could never be used to interact with Word anyway and that is the major reason that AWA's were never adopted - no programming language.
3. I know the client likes his current reports. You might be able to replicate them with Access reports but probably not since they are no where near as flexible. However, when using OLE automation, i personally prefer to automate Excel rather than Word. It provides a much more logical and therefore easier to control with code object model.
4. If you actually need web access because the users are not all connected to the same LAN, you can use Citrix or RDP to host the Access application and run it via a web browser. The Access app actually runs on the server and the only interaction with a remote user is keystrokes in and desktop images out so Citrix and RDP are very efficient.
5. I've created applications that manage thousands of word documents. The apps use cross reference tables to map data fields to bookmarks. This technique will not help you though since it doesn't lend itself to report type displays which is why I would recommend Excel.
6. Since you don't develop in Access yourself, you might want to consider hiring a consultant to do this project for you. It is pretty advanced for someone with no experience.


1. Will some dialogs be presented by Access VBA, and some by Word VBA? All dialogs would be controlled by Access
2. Do free-text fields present an issue in Access? No. But font changes and color differences could. There is a RichText option for memo fields that uses embedded HTML but I'm not sure what happens if you push that out to Word or Excel. All the formatting codes might get stripped. I would check this early and adjust the process if necessary.
3. Should I conceive this as solely an Access-controlled series of data-entry forms and then as a final step, through the use of some kind of Word template, have Access populate and generate that Word doc through OLE or DDE interprocess automation of Word? Yes, an Access FE with an ACE BE and reporting done with Excel if Access can't produce the look you want. Excel will be easier to control than Word.
4. If so, would that only work with a local instance of Access? Access is ALWAYS only local. Access runs on the client PC. Only by using Citrix or RDP can you run Access remotely. The BE database is stored in a shared folder on the LAN and each user has his own personal copy of the FE on his c: drive. The Citrix/RDP setup is slightly different but users still each have their own personal copy of the FE.
5. If the database could be remoted, would it require SharePoint? Access can connect to SharePoint data although SharePoint isn't a relational database so I don't recommend it. I would consider using SharePoint for data collection if the app required it though.
6. If so, would Access handle it? Would it require SQL Server? SQL Server would only be necessary if you had more than 2g of data or more than about 50 concurrent users. Jet and ACE can support tables containing millions of rows. The limitation is only on total size of the database.
7. Is this a kind of application practicable online in a browser? Not if you use Access. You would need to create the application using ASP or something else or as I said several times - use Citrix or RDP.
8. Is this app suitable only to the so-called split database approach? The split database approach separates data into one database and all the other application objects in another. This is the ONLY recommended configuration. Any application that uses a monolithic approach jeopardizes data and makes updating the FE objects very difficult.
9. Ideally the legacy doc at his elbow, so to speak, would be updated in near realtime as the dialogs pop and he navigates through them. Normally when Access is updating Word or Excel, the document is hidden until the data push is complete. Having the document visible just slows everything down. Also, existing documents are not updated. New documents are created either from scratch or from a template.
10. Is that practical in a remote database scenario, or, even a local db scenario? If you run the application using Citrix or RDP - ALL processing takes place on the server and ALL databases (FE and BE) as well as document templates are stored on the server.
 
Last edited:

isladogs

MVP / VIP
Local time
Today, 12:01
Joined
Jan 14, 2017
Messages
18,186
Pat & Doc have already given you very detailed answers which I won't try to add to.

However do consider whether exporting Access reports to PDF would be a satisfactory solution for your client. All the work would be done in Access & the PDFs would look EXACTLY like the Access reports. MUCH simpler to implement and this certainly could be done by an Access newbie.

Otherwise, as Pat suggested, I would pay a professional developer to do this for you as its going to be difficult & tedious to do well
 

AvantGuy

neophyte
Local time
Today, 06:01
Joined
Mar 25, 2018
Messages
22
Doc, I'm grateful for such an expansive reply to an OP I worried was too meandering.

IN THEORY, you can run VBA behind Word - but it is easier to run it behind Access and use Access automation methods on Application Objects (such as Word) to generate what you want to see in a particular Office-member format.
I suspected this to be the case. I was bewildered by what seemed to be two or three possible architectures with a couple different automation libs (OLE, DDE) to choose from.

Clarify your definition of free-text.
I should have written "large text", around 180 chars (max), so, variable length. Only to the user is it free text :--)

Access really DOES NOT LIKE (let's even say VIOLENTLY DISLIKES) environments in which the shared parts are NOT connected via hard-wired circuitry.
You must be eliminating even a hardwired local net (ethernet) with Access as a server, leaving a local instance of Access on the user's workstation as the only viable option nowadays.

Oh, I guess not, exactly:
Access likes Ethernet backbones. Using wi-fi or any other networking technology that exhibits unstable connections will kill Access databases.
Right, in a million years I wouldn't consider that.

My first computer programs were written in 1968.
You're ahead of me by four years. My first code was for DEC's PDP-8, in their assembly language.

Access is dumber than a box of rusted garden tools.
Love it (the manner of expression, not necessarily the info conveyed)!
 

AvantGuy

neophyte
Local time
Today, 06:01
Joined
Mar 25, 2018
Messages
22
Thanks for jumping in, Pat...

Access will be an excellent tool for this project provided you do not have requirements to interact with the application over the web. As Doc already mentioned.
That was a deployment phase-two aspiration. That does put me into a bit of a quandary. Are there any local net (i.e., hard-wired ethernet) options with Access? I'd even consider behind the router WiFi (only two workstations, in the same building -- a private home), just after replying to Doc I'd never even consider WiFi (I'm hoping he meant public WiFi-internet in his admonition!).

Besides, AWA never supported VBA
Oy. That's somewhat disgusting, but if latency over the web is a reason, I understand.

I know the client likes his current reports. You might be able to replicate them with Access reports but probably not since they are no where near as flexible. However, when using OLE automation, i personally prefer to automate Excel rather than Word.
In principle, he's amenable to using Excel, however... Before I had full clarity of the necessity of a database for the app, I preferred Excel and recommended it. This on the basis of multiple worksheet sets and linkages one can achieve.

But formatting for print is just not a strength of Excel and I can't see getting my client what he wants with the rigid grid of a spreadsheet. Word's ability to vertically juxtapose tables each with different number of columns and column widths yields a formatting that he's not going to give up, largely because of the density of info one can present in a single printed page. Another reason I ultimately rejected Excel is the absence of the date-picker control, notwithstanding some workarounds I've seen on the web. If you can correct me on these points I'd like to know.


If you actually need web access because the users are not all connected to the same LAN, you can use Citrix or RDP to host the Access application and run it via a web browser. The Access app actually runs on the server and the only interaction with a remote user is keystrokes in and desktop images out so Citrix and RDP are very efficient.
The users can exist on the same LAN (at least via WiFi but thankfully behind the router), plus they will not be concurrent users. There exists tight budget issues. The client is my brother and his is a business that holds a staff of one person -- himself.

The ongoing maintenance of this app would be on his shoulders as well. I could count on him for database backups and possibly monitoring of logs for exceptions, but not any more than that.

Since you don't develop in Access yourself, you might want to consider hiring a consultant to do this project for you. It is pretty advanced for someone with no experience.
I've done some SQL against an SQL-Server backend, but no VBA to speak of, so, yes you're right, my experience lies in other areas (I don't have enough posts yet to drop in the link to it, but my intro is still at the top of the Introduction Forum).

Pat, your answers to all ten of my questions here are deeply appreciated and are helpful beyond measure:
1. ... All dialogs would be controlled by Access
2. ...
10. ...
 

AvantGuy

neophyte
Local time
Today, 06:01
Joined
Mar 25, 2018
Messages
22
Pat & Doc have already given you very detailed answers which I won't try to add to.

However do consider whether exporting Access reports to PDF would be a satisfactory solution for your client. All the work would be done in Access & the PDFs would look EXACTLY like the Access reports. MUCH simpler to implement and this certainly could be done by an Access newbie.

Otherwise, as Pat suggested, I would pay a professional developer to do this for you as its going to be difficult & tedious to do well

That's a very fine thing to know, thanks ridders. I think it's a good solution, at least for the demo that my client and I will iterate on during the specs development phase. For the production version of the app, I was recommending emulation of his legacy Word doc as a backup in case of server hardware breakdown or failure of the new app itself; i.e., my own failures, mostly, such as the database collapsing because I failed to notice the potential for a cartesian explosion. So, another small quandary!
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 05:01
Joined
Aug 30, 2003
Messages
36,118
Last 2 posts were moderated, I'm posting to trigger email notifications.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 08:01
Joined
Feb 19, 2002
Messages
42,970
That was a deployment phase-two aspiration. That does put me into a bit of a quandary. Are there any local net (i.e., hard-wired ethernet) options with Access? I'd even consider behind the router WiFi (only two workstations, in the same building -- a private home), just after replying to Doc I'd never even consider WiFi (I'm hoping he meant public WiFi-internet in his admonition!).
Access is multi-user out of the box. The FE (which is the application part that contains the forms/reports/queries/code) is distributed so that each user has his own personal copy and each copy of the FE is linked to the same copy of the BE (data only) which is stored on a network drive so everyone can share it. Templates of the Word or Excel reports would also be stored on the server.
In principle, he's amenable to using Excel, however... Before I had full clarity of the necessity of a database for the app, I preferred Excel and recommended it. This on the basis of multiple worksheet sets and linkages one can achieve.
I am recommending Excel ONLY for output not to run the show. Everything would be controlled from Access although the workbook might be a template if it helps with the formatting.
The users can exist on the same LAN (at least via WiFi but thankfully behind the router)
If the LAN is WiFi, then do NOT use Jet/ACE as the BE. Use SQL Server. Jet and ACE CANNOT recover from network interruptions and so would be flaky on anything less than a top-notch stable LAN and I haven't seen one yet. SQL Server Express is Free and can be run on a PC. It won't require a server given the small amount of traffic you will have. The management of SQL Server is more complex and you should probably hire someone to set it up so that backups are created appropriately and are kept for long enough to recover from data loss. Setting up SQL Server isn't difficult and I've done it a number of times for test environments but I am not a DBA and would never presume to do this for a production database. The risk is too high.
Another reason I ultimately rejected Excel is the absence of the date-picker control,
That has nothing to do with anything. Word or Excel are ONLY formatting output. They are not developing it or doing data entery. They are "printers" only.
The ongoing maintenance of this app would be on his shoulders as well. I could count on him for database backups and possibly monitoring of logs for exceptions, but not any more than that.
There are excellent, reasonably priced tools for this that are sold by FMSINC.com

I think you'll find that once you start developing in Access, you will deviate from the existing application either because you found a better solution or because you have new requirements so I wouldn't hang my hat on having a safety net for very long.
 
Last edited:

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 07:01
Joined
Feb 28, 2001
Messages
26,996
It has been mentioned in passing by Pat and Ridders, but I meant ANY Wi-Fi at all. The potential for intermittent connections is too high and the damage done by lost network links is too high to EVER consider it.

The reason Pat said Access FE + SQL engine BE might work is because for the most part, you can pass queries to the BE and have them executed locally (with respect to the server) and then get results passed back.

The damage to which I referred occurs when you have an all-Access DB (both FE and BE) and in this case, the work is done on your FE machine using SMB protocol. Since that is a TCP class of protocol (as opposed to UDP), it has sequence numbers in each header and it uses negotiated ports. If the network drops, you suddenly have dangling ports that can NEVER reconnect unless your network ALLOWS a reconnect. Most don't, for security reasons. The problem is that with the FE doing the work, the changes to the BE have to be sent over the network. If you have a sequence of updates and experience a network drop, you now have an incomplete set of updates. You can imagine just how ugly Access would treat you under those circumstances.

On another topic, ... PDP-8, eh? My first DEC systems were DECSystem 10's based on the KA10 CPU running TOPS-10. Nice, big hulking room full of beast. But before that I used the old IBM 1620 Mod II, which was - to say the least - interesting. It wasn't a true binary system. It was decimal-based using BCD encoding for each digit.

Back to business...

I was bewildered by what seemed to be two or three possible architectures with a couple different automation libs (OLE, DDE) to choose from.

This is why so many people have a love/hate relationship with Office. It gives you an incredible array of options. For the professional, it is great! For the beginner, it is the worst of all possible nightmares. Don't feel bad about being confused over what to do.

I should have written "large text", around 180 chars (max), so, variable length.I should have written "large text", around 180 chars (max), so, variable length.

Using a "short text" field in the underlying table, you can get 255 characters in a single field, which could be served by a single text box. However, if I recall correctly, that doesn't give you any room for rich text options.

Access as a server

Never happens. Access is either the whole schmeer or is a client. In the case of a split database with front-end and back-end (FE/BE), it is possible for Access to be the FE and have something else (SQL Server, ORACLE, SyBase, and a few others) as an active BE server. But Access wouldn't be the BE server ever.

As to my colorful language, sad to say I wasn't kidding. Access is a tool. Think like a carpenter for a brief moment. Access is like a power handle that lets you insert various working bits like drill bits, nut driver bits, screwdriver bits, buffer bits, sander bits, etc. But if you want to make a French armoire, YOU will be the one who has to use the tool correctly. The power tools won't make the armoire. YOU will.

Which is why I stated that Access was dumber than a box of rusted garden tools. But I WAS being a bit harsh. The Access wizards that are a major part of the "Rapid" in "Rapid Application Development Tool" can quickly build very nice "scaffolds" for you that can then be customized easily - and incrementally. You see, Access DOES know forms, controls, reports, and the like. It just doesn't know applications. Which is the source of the comment about YOU being the subject matter expert.
 

AvantGuy

neophyte
Local time
Today, 06:01
Joined
Mar 25, 2018
Messages
22
PDP-8, eh? My first DEC systems were DECSystem 10's based on the KA10 CPU running TOPS-10.
Phew, takes me back. You ARE an old programmer :--) I'm a young programmer (okay, I'm in a state of denial!). The bulk of my DEC experience was under PDP-11 RSX-11.

Thanks, Doc, for the additional perspective. I understand it all, so, no further questions. ...well, until I'm fully into the weeds of course.

--Bob
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 08:01
Joined
Feb 19, 2002
Messages
42,970
OMG, thanks Pat. So very helpful!
Just to be crystal clear, only the data should ever be shared. I've mentioned several times that the FE (application parts) and BE (data) are physically separate databases. Each user is given his own copy of the FE much the same way that you have your own copy of MSExcel.exe on your computer and you and Suzie don't share a copy of MSExcel.exe on the server. While the BE (data) is placed in a shared network folder and all the FE copies link to the same BE copy.

When you get to the point of needing to distribute the FE, we can offer suggestions. I use a very basic .bat file. Each user has a shortcut to open the app. The shortcut runs a .bat file located on the server. The .bat file downloads the current version of the FE and then opens it. This ensures that the user always has the updated copy of the FE. Other people use more sophisticated distribution software.
 

AvantGuy

neophyte
Local time
Today, 06:01
Joined
Mar 25, 2018
Messages
22
Just to be crystal clear, only the data should ever be shared. I've mentioned several times that the FE (application parts) and BE (data) are physically separate databases. Each user is given his own copy of the FE much the same way that you have your own copy of MSExcel.exe on your computer and you and Suzie don't share a copy of MSExcel.exe on the server. While the BE (data) is placed in a shared network folder and all the FE copies link to the same BE copy.
This I understood from the previous replies. I do recall being on a project, at least 15 years ago now, where Access was FE to SQL Server. The db designer liked the ease and friendliness of the query side, including ad-hocs, IIRC. I was directly involved on the server side because my data collection application, which logged on to remote telecom devices around the countryside and requested records dumps, did insertions into a server table. I chose to use ODBC as the db interface because management insisted we also must allow users to chose Oracle <sigh>. My app was C++/MFC, and ODBC seemed the only portable interface at the time. When it turned out they never sold a system with Oracle, even to existing Oracle shops, we decided to toss ODBC and go with a decently performing method. A colleague wrote a pretty hot C++ wrapper for low level db calls. It then began to scream! A long winded way to say that my long software dev experience allowed me to read between the lines, although I think you and everyone here have always been very clear.

When you get to the point of needing to distribute the FE, we can offer suggestions. I use a very basic .bat file. Each user has a shortcut to open the app. The shortcut runs a .bat file located on the server. The .bat file downloads the current version of the FE and then opens it. This ensures that the user always has the updated copy of the FE. Other people use more sophisticated distribution software.
Oh, that's cool. I appreciate the tip.
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 05:01
Joined
Aug 30, 2003
Messages
36,118
Post 14 was moderated, again posting to trigger email notifications.

AvantGuy, the forum should stop moderating your posts after 10 or so. Not sure why it is now; usually it's links that trigger it.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 07:01
Joined
Feb 28, 2001
Messages
26,996
The bulk of my DEC experience was under PDP-11 RSX-11.

My first commercial-world job before I became a government contractor was to be a device driver writer and interface testing utility designer under PDP-11 RSX-11M. A later job, also before going into the contracting world, was to do navigation systems based on a set of proprietary navigational beacon receivers for a non-disk RSX-11S that would get loaded from tape and would write navigational position logs to tape synchronized with offshore oil echo-location (seismic) systems. My dissertation research was done on a PDP-11/15 running a stand-alone O/S, I think RT-11. The PDP-11 was my favorite machine until the VAX-11 came along. All of my main work on those machines was in Macro-11 or Macro-32, though the VAXen had FORTRAN, PL/1, and BASIC.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 08:01
Joined
Feb 19, 2002
Messages
42,970
Access is an excellent FE for any ODBC data source. The nice thing is that as long as you are using linked tables and Access querydefs, the SQL is transparent. Of course, you are limited to Access' version of SQL syntax which is a little long in the tooth at this point. I have a couple of apps that are sold to the public and the user can choose to install with an SQL Server BE or with ACE. They can also use Oracle or whatever but I only provide a .bak for them to load in a current SQL Server format. There is only one procedure where I actually needed to write separate code to accommodate SQL Server.
 

Users who are viewing this thread

Top Bottom