Solved Can You Restrict Important Info In Azure If Customer Owns Azure Subscription? (3 Viewers)

[dalski]

Thanks Doc. I've barely scratched the surface of absolute novice of SSMS/ Access & learnt what a SA was about 3 minutes ago so we can ascertain everyone on the forum is more capable than myself.

The only experience I had working with SSMS prior to this was using the app mentioned elsewhere where the publisher deployed SSMS locally to client's. I never had much problems with their account. I mistakenly deleted some foreign keys (when I didn't know what a foreign key was in them days). They provided scripts for these typical prob's. That was the only problem I encountered when using. I would imagine 'memory flush's' would be a script & possibly a password protected account with SA type privileges, so that is effectively the SA account protected with a password. Security Patches - what there would affect the main functioning of an Access db implementing SSMS? Are you saying the db needs to be rewritten on every update patch? I was worried about this kind of thing but surely essential methods... are not going to be changing on patches affecting the running of the app? I know .NET is a pig for this.

Leave the sys admin account like it is. Don't EVER interfere with it's operation. EVER. That is a black hole of information loss waiting to collapse. HOWEVER, you certainly CAN protect the admin account.

Thanks noted, I won't do that then for sure. My plan was any probs they call me & only I know the password of an elevated role & login remotely was my thoughts.

Again massively inexperienced, don't pretend to be a know it all, I'm just looking for pointers by others, which I'm most grateful of. Barely scratching the course it seems you can apply certain security/ privileges through users/ schemas/ many different class types/ whatever the term is but the point is they can be applied covariantly. As my user privileges/ structure is so simplistic I this will not be awkward to implement later & will probably apply covariantly via schema's (famous last words ) in restricting certain permissions/ roles (exc'd the SA account here; that's the problem; I would've thought renaming the SA account & adding a password gives me the option to access in the future but only by myself; it's effectively a SA account but mitigates the risk of users reverse engineering).

No doubt I'll cause some laughs with my ignorance - which I look forward to learn.

 

[RonPaii]

Surely that system will eventually require attention by a SysAdmin, such as for example when MS publishes the next round of patches. Happens every other Tuesday. Also, MS has done a lot to reduce memory leaks. But once memory gets all full of crap from those few remaining leaks, someone with admin rights has to go in to initiate a flush.

There is this minor issue that your SA is also a ROLE, not just a singular account. In fact, if you go by U.S. government standards, the actual "Administrator" account is never used except in very specific circumstances. Instead, the assigned admin has TWO accounts - one more or less a strong user ("power user"?) and the other is a true admin account. The admins normally do their "thing" via the power account and will only log in as a full admin when necessary.

Principles of stability and preferred practices as suggested by various security organizations suggest that the sys admin account MUST NEVER be compromised. The idea of blocking it pretty much guarantees that at some point you will be painted into a corner from which you can ONLY escape via the sys admin account.

My qualifications for speaking authoritatively on this are 28 1/2 years as a sys admin for U.S. Navy servers and about 8 years as a sys admin for a local company in the oil & gas industry plus another 3 years as the assistant admin for another oil & gas company. I hold an HP Certified System Administrator certificate for OpenVMS and a CompTIA Security+ certificate, the latter renewed four times for updated standards. I used to teach system security to other Navy admins. My advice is simple: Leave the sys admin account like it is. Don't EVER interfere with it's operation. EVER. That is a black hole of information loss waiting to collapse. HOWEVER, you certainly CAN protect the admin account.

Suggested government standards for a Windows sys admin account password are (a) not less than 15-character passwords (b) using at least 1 each of upper case, lower case, digit, and punctuation characters - but our site used at least 2 of each class (c) and changed once per month.

I have seen in a number of places that the SA account should be disabled on SQLServer.

 

[dalski]

Thanks Ron, yes I've seen quite a few articles stating this & linked previously. Granted my input has little value. If you created a 'role'/ whatever that effectively has SA permissions but password protected the different username with effective SA privileges you would remove a general SA hack I would've thought.

 

[The_Doc_Man]

Security Patches - what there would affect the main functioning of an Access db implementing SSMS? Are you saying the db needs to be rewritten on every update patch?

No, it is that an SA might have specific actions to perform in order to apply patches, particularly if the system option has been engaged to hold patches to a convenient time. The DB might or might not be affected because MS patches whatever they feel NEEDs to be patched based on recent hacker attack patterns. Patches are like a giant kaleidoscope (or, per Forrest Gump, a box of chocolates). You never know what you will see. Would the DB need to be written? Unlikely. Would parameters on the DB-related utilities need to be adjusted after a patch? It has been known to happen. See also your own thread on SSMS22 vs SSMS21, where somehow a speed difference between versions is involved and the odds are that the difference was related to an MS patch to SSMS with an unknown side-effect.

 

[DaveMD]

Based on this thread, the OP seems to have two objectives:

1. Help ensure customer has sufficient licenses to use the OP's application.
2. Protect certain parts of the application logic considered to be Intellectual Property.

There seems to be confusion in many areas in differentiating what might relate to these objectives versus other things when it comes to using SQL Server for the backend. Below are some areas that may help clarify.

Area	Notes to Help Achieve / Explain
Addressing Objective 1	Develop a written licensing agreement between you and the customer. This should specify the Terms of Service, such as how many concurrent users the license covers, how many machines the front-end application can be used on, etc. If the client does not abide by the terms, the agreement would provide a basis to seek legal action.
	Develop some licensing enforcement into the front-end application. For example, you could have logic in your compiled accde VBA that would limit how many active users are supported. This could be checked at application start-up. Avoid going overboard with this as you don't want it to be so restrictive and finicky that it causes issues for your customer to use the application as intended. For example, Intuit several years ago tried to add all sorts of licensing protections into TurboTax that ended up being so restrictive that they lost some of their good paying customer base -- too many headaches to use your software as a legitimate customer can translate to your application no longer being worth it to the customer.
Addressing Objective 2	Compile your front-end into an accde file and distribute that to the client. This will protect your code to a reasonable extent. It won't protect someone malicious from trying to reverse engineer but this concern is often overstated provided you have entered into an agreement with a paying customer. Typically those who have paid for your application are concerned more about having sound software and support for their business purpose rather than trying to hack your product.
	For Stored Procedures in SQL Server that you consider to have Intellectual Property, encrypt them as already suggested by others in other posts above.
SQL Server notes that are not reasonable and/or will not help with Objective 1 and 2.	Do not attempt to restrict your own customer from being able to administer the backend SQL Server database / environment. This is not only not feasible but it is unreasonable. There seems to be confusion in this thread in this area. The client will have their licensing with Microsoft for SQL Server (assuming they are not using just the free Express version). The database for your application is quite likely one of many SQL Server databases your customer utilizes/manages. Your customer would and should have the ability to administer their SQL Server environment -- not only to apply patches, but also to implement sound database backup and recovery processes, etc. All of these things require system administrator level access.
	There is a difference between SQL Server database roles/permissions and instance level logins and permissions (like sa). For example, for the database for your application, you typically will define certain functional roles that will be used by the application (PurchasingInitiator, PurchasingSupervisor, AccountsPayableInitiator, AccountsPayableSupervisor, etc.). But at the instance level, your client is going to have at least one database administrator (DBA) with sysadmin permissions. Technically, sysadmin allows that individual to manage all databases in that instance and have access to manage all data, manage permissions, and technically they could also change table definitions, delete objects, make and restore backups, etc (basically do anything). However, the DBA is responsible for managing things well in an organization and it would be "on them" so to speak if they maliciously or carelessly modified things in the backend database for your application. Remember, your customer needs their systems and databases to work properly for their business purposes and be safeguarded in case something goes wrong (if a flood destroys the server, it would be on the customer/DBA to ensure they have adequate off-site backups to be able to recover).
General terminology confusion	Throughout this thread, the OP seems to refer to SQL Server as SSMS. As others have noted, these are two very different things. SSMS is simply one of several tools that can be used to manage a SQL Server instance/database. SSMS can be installed on a machine without SQL Server being installed on that same machine. Referring to SSMS as if it is SQL Server would be a little like referring to your website as Google Chrome (a tool to access your website). To help avoid confusion in communication, you can just refer to it as SQL Server or MSSQL. If you are trying to refer to SQL Server's flavor of the SQL language, you can refer to that as TSQL (which stands for Transact-SQL). To differentiate Azure based SQL Server from on-premise SQL Server, you can just indicate Azure SQL versus On-prem SQL Server.

 

[The_Doc_Man]

@dalski - you commented (in one of your recent posts) about getting information about what Windows does. May I recommend a series of YoutTube posts under the general authorship "Dave's Garage"?

Not every one of the posts will be helpful, but his titles are general reasonable so you can filter out what you don't want - or maybe just don't want at the moment. Dave has some really interesting posts. One of his guests in the last couple of years was Dave Cutler, who was one of the primary authors of Windows NT. That is the first version of Windows that did not ride a DOS code core; rather, the "DOS layer" (CMD task) became an app under a Windows code core. Dave (of Dave's Garage) is also the author of the Windows Task Manager and has a couple of articles about that most useful of utilities for finding and terminating runaway tasks - as well as finding other task related problems.

 

[dalski]

No, it is that an SA might have specific actions to perform in order to apply patches, particularly if the system option has been engaged to hold patches to a convenient time.

Very important input here - thanks Doc. Was worried about this & vomited when reading. I feel this is the biggest problem with modern software development; a constant changing environment which is unproductive, pushing Microsoft's failure onto developers to address. I stop updates on my machines & everyone I know does. They cause more problems than they save. We all remember the recent global chaos caused by Crowdstrike.
My T&C's will be sold on the security patches from a sepc'd date. Maybe check every 6 months or so & give users the option to update to spec'd patch though I imagine it would be extremely difficult to ascertain what would be going wrong should any problems arise.

 

[The_Doc_Man]

Oh, holy guacamole, NO NO NO! You are looking at patches entirely wrong. Some years ago, the SANS Institute (you can look them up if you like) released a list of the most common causes of computer issues (such as hacking, code failure, incompatibility with a network partner, data theft, etc.) One of the top five causes was "failure to keep a system patched." May have been as high as 2nd on the list.

The patches are your 2nd line of defense. (Good network firewall is your 1st line.) That low-hanging fruit I mentioned in another post is dangling there, waiting to be plucked, and if you don't have up-to-date patches, it is not only just hanging there, it's not even a moving target. Blocking all patches to a six-month interval is like sticking your head in the sand with your butt still up in the air, waiting for the inevitable. A static defense has NEVER worked. The Great Wall of China didn't work to keep out the Mongol hordes. The Maginot Line didn't work in European wars. Why should yet another static situation stop that which is constantly moving, constantly testing, always looking to find a weak point?

From Sentinel One, this is their list. Check #4

1. Malware
2. Phishing attacks
3. Password-related vulnerabilities
4. Unpatched software vulnerabilities
5. Insider threats

I feel this is the biggest problem with modern software development; a constant changing environment which is unproductive, pushing Microsoft's failure onto developers to address. I stop updates on my machines & everyone I know does.

This is a failure to recognize the difference between ideality and reality. It is one thing to choose when to install patches (and to do the required testing thereof). It is another thing entirely to stop patching. Get some anti-nausea drugs and start planning for running software with real-world exposure. A good firewall helps, but if you have external customers who have to come in through a network connection, it can't be a perfect blocker.

 

[dalski]

like sticking your head in the sand with your butt still up in the air, waiting for the inevitable.

Thanks Doc, I don't think I need to worry; my butt just aint that enticing! Cool - test each patch before then email/ permit each patch update & allow the user to install should they desire; got it. Thanks for warning me.

 

[CJ_London]

- test each patch before then email/ permit each patch update & allow the user to install should they desire

Lost track of your chosen pathway - but if your client has an IT dept ( who will have their own patch strategy) or just has a policy in conflict with yours, think you will struggle with that approach

Not quite the same thing but I have clients who use outlook automation and I’m constantly having to remind them not to install new outlook over classic if they want to continue to use automation.

 

[dalski]

Lost track of your chosen pathway - but if your client has an IT dept ( who will have their own patch strategy) or just has a policy in conflict with yours, think you will struggle with that approach

Thanks CJ, agreed - I see a future I do not want to look at here. Seems an impossible task to maintain a consistently changing environment.

 

[CJ_London]

Which is why, if your product is so valuable you should be looking at a web solution. An alternative is to use terminal server - which has a licensing cost, can use your access FE and can be accessed by any device that supports TS. You control access to the server and can apply patches/updates as required

 

[dalski]

Thanks CJ, I don't disagree with the security with Access. Some sources suggest that moving the BE to SQL Server would obfuscate business logic. At the moment this seems downright wrong & it would have been safer to stick with Access' JET Engine with a compiled .accde as suggested by @AHeyne, I think this is a strong case Mr AHeyne. Moving BE to Azure to obfuscate - yes; but not SQL Server. Encrypted Stored Procedures are so weak the bother of encrypting them does not seem worth it.

Terminal Server (TS) - thanks. I wonder what the differences are with TS to a Virtual PC on Azure. Oh I see the benefit of handling the updates now; thank you. All these subscription costs are just out of hand nowadays & I'm looking to bring things back to the good old days when you bought an application; it worked as advertised as the day you installed it without it going to the next day from an update & TS seems a brilliant solution here; but don't like the subscription cost. As possible solutions later possibly a fixed IP address & a dedicated pc of my own handling Remote Desktop connections/ VPN which are notoriously bad with Access it seems... I've messed around with beginner projects on Raspberry Pi's with RDC's... & I thought a secure shell was all that was needed... But a long time ago... One would think you'd just need to encrypt your connection with certs.../ whatever & manage your own users...

if your product is so valuable you should be looking at a web solution.

Having already taken basic courses in C# & C++, C, HTML, CSS, PHP I wonder if I have made a mistake in trying to master Access & develop this in Access to see if it works. If I've struggled in Access (still not finished it) then I'd likely not complete it at all in C# I think & they were only basic courses. It took me ages to get my head around replicating inheritance in VBA (a horrible, horrible thing). I do wonder if I have chosen the best route in learning Access, I love it, I just wonder if it was the right choice.

Development Further Down The Line - C# would be my preference I think BUT the same issue arises with .NET I believe:

 

[The_Doc_Man]

All these subscription costs are just out of hand nowadays & I'm looking to bring things back to the good old days when you bought an application; it worked as advertised as the day you installed it without it going to the next day from an update

This is now one man's OPINION, not to be considered as a proven fact: The reason the "good old days" seem so desirable isn't that those days were so good, but that we were so naive as to not recognize what was really happening at the time.

Times haven't changed. People haven't changed. Only the tools have changed. Per businessman Mitch Ratcliffe, "A computer lets you make more mistakes faster than any invention in human history, with the possible exceptions of handguns and tequila."

Other similar quote: "To err is human, but to really foul things up you need a computer." (multiple attributions)

 

[CJ_London]

I'm looking to bring things back to the good old days when you bought an application; it worked as advertised as the day you installed it without it going to the next day from an update

Therein lies your problem - trying to sell a model T ford in today’s market.

If your app is fully inward looking and does not integrate with other apps (such as outlook or web technologies) then the code should continue to work regardless of other changes - at least for 20 years or so. I developed an app over 25 years ago which would still work today (client was taken over around 8 years ago and the buyer used their own app). Yes, there were enhancements along the way to meet the requirements of a changing market but providing the user continued to use access/office 2003 or later (32bit versions only) the original app would continue to work

 

[GPGeorge]

From time to time we hear about legacy apps running on Access 97/2003/2007 etc.

The defining characteristics of such apps generally include isolation from integration with other applications and a business model that hasn't changed since dirt was invented. That's fine where it works. Until it doesn't.

 

[CJ_London]

That was my point

 

[Albert D. Kallal]

Ok, first up, I’m a bit confused by all this talk of patches, updates etc.

At the end of day, one wants to:

Sell, and deploy some software to users.

Such users don’t care about backups, patches, etc. They JUST want to use the software – nothing more, nothing less.
They will NEVER had to deal with things like OS version etc. as a result of YOUR software. No different when you install word, or QuickBooks accounting.

Now, of course you want some type of license key system.
Probably best to use a web-based system for that part (that Access can talk too and check licensing, or for updates).

However, on the desktop software part?

You just install the software – you are done…….


I have for many years deployed commercial software (including Access) based on the above simple model.

You need to REALLY spend time on installing of software, and ease of uprading softwre.

And also time for REALLY easy support of your software.

In fact, I included a “built in remote help” system based on VNC – the free open-source desktop sharing system.

So, if a customer needed support? Two mouse clicks, and we seeing their desktop - no software installs, no downloads, no funny "long number" to type in. Why all that "junk" to JUST help a customer?????

So, the customer steps for a remote support session for this Access application?

This:

Then this:

then:

Then

No funny numbers, no nothing – just a few clicks and we sharing the customer’s screen. (and it worked though all fire walls etc. – this worked because I had a “repeater” server setup for this purpose).

And updates?
You REALLY need a installer here…… but REALLY!!

So, a customer can update – say like this:

then:

Then

then this:

And the reasons are many for “ease” of update. One reason? Making money!

So, customer needs a 100% hassle free way of installing your software. And if you do this right? You include the ability to deploy updates (so, software on startup can check for an update).


So, often, a customer would phone me up, and ask if I could add some feature x, y or z?

And if the feature was a good idea, one that just about all the other customers would want?

I would say sure, happy to provide this new feature and update. I would charge them say $75 dollars.

Then, I would send an email out to all my other customers telling them that a new version with a great new feature is available – for just $75 dollars. And in most cases, since that idea was a good idea?

(I mean, after all, they are all in the same kind of business – right???). So, it is HIGH likely that other customers would agree with this great new idea!

And sure enough, at least 20 of them would say yes, that’s a great new feature.

So, I didn’t just make $75 for the 1 hour that new feature costed me to add, but just made 20 x $75 = $1,500 for that one hour of work. But you can ONLY do this trick if you have a VERY easy way to update your customers (hence, we taking about an automated system). And that update system was actually rather easy to setup and was written in VBA.

So, updates and installing? It BETTER be easy, and hassle free for you and the customer!

So, we have to keep 100% separate that of deploying the software, vs that of sharing the database, vs that of licensing issues.

So, next up:

Is the database to be multi-user, or is the data to be 100% stand alone for each copy of the software?

Once again, customer does not care, or even have to know how, or where the data is stored – they JUST want to run + use the software.

Today, 100’s of millions of people install applications on their smartphones, and 99% of them have some server-side system – a system that the end user NEVER cares about.

And even windows are moving towards a “app store” like experience.

So, when I sold a copy of my application (written in Access), the data was hosted in SQL server, and later on, I used SharePoint.

So, the above model was not unlike how phone software works. You near always sharing data, and using some server system, but the user(s) never cared.

So, I do recommend using a web site for support - that web site can have help files, can handle licensing issues, and allow updating of your software?


Now, next up:

Is the data (database) to be shared for a given customer/company. So, say they might want 5 copies, and those 5 copies can be run with any internet connection, and they are all sharing the data?

I am assuming yes here. So, could you use Azure for this? Sure. But, once again, the user will not care how this works, or how this is done.

I mean, do users here reading this post care ONE BIT about what database is being used to store this post????
(nope!!!).

However, this does bring up some issues, and one of them?

If you looking to deploy software, reduce deployment costs, then I would consider a web-based version of your software.

So, all this talk about OS patches and updates?
Since when buying QuickBooks is the customer to be worried about some OS update?
This discussion makes little sense here.
We have to assume that customers have a working computer – OS updates etc. is THEIR problem, not you the software vendor.



So, in summary:

Licensing keys, and software updates?

Yes, it is a given that you will have or build a system to take care of above – quite much the same as looking out the window, and pointing out that we often see blue skies.

And it’s actually not all that difficult to achieve the above.

So, then, the only next real question is does a given customer need/want/will have more then one seat, and thus are they to be sharing the same data?

So, then the question becomes:

Will those users all be at the same office location?

If yes, then you can use a classic Access front end, and then a back-end access database. This setup does not in ANY way remove options of licensing keys, and even over the internet front end updates for your software.

However, if you want people at home, or work, or even any location with internet to “share” the same database? Well, then yes, now you back to using a shared (and hosted) database. In that case, I would actually consider setting up a server for this purpose – even if it is hosted and NOT use Azure - since you need more then just SQL server to support your customer base.

So, with that server, you can:

Provide license keys, updates to software.

Provide shared database (assuming shared anywhere with internet is required).


However, once again, the instant you plan to provide some shared database system is the instant that YOU are incurring monthly costs (and thus they are not JUST buying the software, but also consuming your efforts on a monthly basis).

So, in place of all of the above?

Well, depending on the kind of software, then I would much consider going web based. The reason of course is that it’s less cost (and hassle) to host a web site then it is to host a full blowen server (to handle all those extra things like updates of front end, and licensing keys etc.).

Building web-based software is more work (and cost) upfront then compared to Access, but you save much back on the deployment model and efforts required to support your software compared to desktop applications.


As noted, I think the efforts to setup Access for a commercial deployment and support environment? Well, that’s quite a bit of extra work, so thus, that’s why I’m saying going 100% web based is something to consider.


Everything else needs to be as transparent to the end users as possible….

Having stated all of the above?


Access is not particularly great for wide commercial distribution of applications. However, using an installer can help boatloads. (and an installer makes your application look commercial – users will never know (or care) that you built this in Access.

Access is not all that great for high levels of security in terms of locking down the database connection, and say restricting data to a given user. You can obtain “good enough” for most use cases.

As a result, for my commercial deployments, I created a whole new SQL server database for each new client (on the web hosting site). Thus, I was restricting data per customer, not per user of that company. I think this approach can scale out to say about 50 customers (and maybe each customer has said 1-5 users). However, if you expect more customers, then using a hosted instance of SQL server and Access? No, it’s not a good idea, and I thus would suggest writing software as .net for the client side (due to security and deployment issues).

R
Albert

 

[dalski]

Thanks Albert, the tone atm is as if user's are happy updating regularly, to break their software. I don't think they are. My opinion is development has gone backwards recently. You used to be able to rely on software working; now many of my app's which cost several thousand a year regularly break due to updates.

Such users don’t care about backups, patches, etc. They JUST want to use the software – nothing more, nothing less.
They will NEVER had to deal with things like OS version etc. as a result of YOUR software.

I agree & hope this is the case. I cannot see how it is a small developer's duty to fix an OS' errors caused by updates.

You need to REALLY spend time on installing of software, and ease of uprading softwre. And also time for REALLY easy support of your software. In fact, I included a “built in remote help” system based on VNC – the free open-source desktop sharing system.

That looks cool, does it allow remote control from the technician to the client?

Is the database to be multi-user, or is the data to be 100% stand alone for each copy of the software?

Multi-user as you say restricted atm by a LAN using SQL Server. Possibly .NET further down the line but I'm struggling enough with Access & SQL Server so baby steps.

And updates?
You REALLY need a installer here…… but REALLY!!

I'm inexperienced here but I would think this is just a procedure/ subroutine/ script & keeping track of changes as you develop?

So, I do recommend using a web site for support - that web site can have help files, can handle licensing issues, and allow updating of your software?

When you say licensing do you mean an external application to handle the licensing or code your own in the FE? I could then have a separate db on website with encryption to handle customer's licensing but wondering how tricky it will be to design. Again not keen on subscriptions.

Is the data (database) to be shared for a given customer/company. So, say they might want 5 copies, and those 5 copies can be run with any internet connection, and they are all sharing the data? I am assuming yes here. So, could you use Azure for this?

Yes but as stated Azure's achilles heel is it's subscription costs & unkown read/ writes leaving me with an unknown bill not being able to claim back from the customer. Don't want to go subscription based on this first version.

If you looking to deploy software, reduce deployment costs, then I would consider a web-based version of your software.

This is the plan but I'm no expert & tried Access first because of it's RAD characteristics & ease of use is what attracted me for version 1. Ver 2/3 in C# probably; if I get there.

So, all this talk about OS patches and updates?
Since when buying QuickBooks is the customer to be worried about some OS update?
This discussion makes little sense here.
We have to assume that customers have a working computer – OS updates etc. is THEIR problem, not you the software vendor.

Thank you, I agree.

I created a whole new SQL server database for each new client (on the web hosting site). Thus, I was restricting data per customer, not per user of that company. I think this approach can scale out to say about 50 customers (and maybe each customer has said 1-5 users).

Thank you for rough numbers, I was thinking of this as an initial ver 2/ 3 to see how it goes & will develop incrementally in difficulty as I go.

 

[Albert D. Kallal]

that looks cool, does it allow remote control from the technician to the client?

Yes, but it works the other way around – the end user has to start the remote session, not that you can! (and I don’t think any customer would give you the ability to remote into their computer).


So, this works like “goto my pc” or “Team Viewer” or many of the other “support” systems. The difference is that I wanted this to work with about 2 mouse clicks – and I didn’t want users to have to hit some web site, and I didn’t want users to have to type in some pass word, and I didn’t want users to have to type in some 15 digit long number. And I didn't want users to have to install additional software. And I didn't want.....(insert 30 more issues of pain points).

And I also wanted this system to work for me, when I’m travelling (say at a coffee shop, or at some other client’s site). So, in effect both of us were “assumed” to be behind a firewall, and it system was to “just work”, and work without pain. So, the end user had to start the request, but it was as per the screen shots built into the Access menu (I of course used a custom menu bar to hide the Access interface, and later versions of course use a custom ribbon).

So, I was using TightVNC, and there was (at that time) a lightweight zero install server that the customer would run (Called UltraVNC SingleClick). This “SC” (single click) version of VNC was super small – only a few 100 bytes , and as noted ran as a simple .exe, and no install was required. If I was to be at my business location, with a fixed IP, then no repeater server would be required.

However, a server running the “repeater” software was required, since both ends could and would in practice be behind fire walls and at un-known IP address. Again, I want this to “just work”, and no fussing around. When people reach the point of needing help, they are already frustrated, and it makes little sense to make their day and experience any worse then it already is!!!

Everything is ALWAYS about creating a great customer experience!



Re: about using an installer

I'm inexperienced here but I would think this is just a procedure/ subroutine/ script & keeping track of changes as you develop?

No, if you ever installed a program on your computer, then you were using an installer. That install does all the setup of your program.

So, it can create the folder where the software will be installed into

So, it can do things say like register a bar code font on the computer (say your Access application prints bar codes – which is super easy, but then you DO NEED to install and have a bar code font on the computer). So, an installer can register that font for you.


So, it can setup and create a short-cut icon on your desktop.


And Access will “nag” the user and not allow VBA to run if the folder you installed into is not setup as a access “trusted” folder. (so, installer can do registry edits for you)

And maybe your Application uses a few helper .dll’s that VBA calls to say allow merging of multiple reports as PDF into one PDF.


And the installer can detect if user does not have Access, and then setup + install the free Access runtime version for them, right?

I can type on and on for what, 100 pages more?

But the general idea?

Setting up software is a huge massive pain and hassle for both you and your customers if you don’t use a installer to do all of the above, right?

I mean, what folder is the customer going to use? Why even ask them, and why even make them decide? (they don’t know, and they don’t care, and they don’t want to care or know anyway!!!).

So, all other software you installed on your computer has a “wizard” like installer to setup software on your computer – makes sense you would do the same, right?

When you say licensing do you mean an external application to handle the licensing or code your own in the FE?

I mean roll your own. It does not have to be web based. I cooked up some VBA code to read a license key. So, I could provide a download link for them, but I would email them the license key.

My license key included their company name.

In fact, this was a great decision!!!

The reason of course is that often employees of one company would move on, go work for another company (in the same industry). Turns out, often they would take a copy of this software they were using and liked to use, and that it helped them do their work (it was a event management system).

But, while I allowed them to freely copy the software? (and did not care if they did)?

The company name was bonded to the license key. So, when launching the software, the company name would display on the main page. It also displayed on the top of all reports etc.

Well, needless to say, no company going to use software and produce reports with say another well known company in town appearing on all their reports, right?

So, sure enough, after a while, that employee would go to their boss, show them the software, show them how great it is to manage their events, and after convincing their boss to buy this software?

Well, then call me up to buy the software!

Well, all I had to do was then have them send me a check, and I sent them a new license key (that had their company name and logo etc. in that key). So, it worked really well, since then as employees over the years moved around and took a copy of my software with them? They became my best sales force!!!

So, I on purpose let them copy my software – even made it really easy to do so!!! But, they could not change the company name! – that was part of the license key. So, then all those employees moving around over the years became my sales force for me!! And the original license key I sent them had a expiry date (since I was VERY happy to send them a key by just a phone call from them, and they would tell me that they would send payment in the mail).

Well, the license key I sent them actually expired in 45 days. So, in most cases, if I received payment, then I would simply send them a new update and license key (to them, it was just another software update). But, that had a new expiry date (or in fact did not have one anymore). For the most part, thus, they never knew (or cared) that their software would expire, since it never did if I received payment. However, often they are busy, and thus I did not receive payment. But, when the software started complaining that it would stop working in 15 days, then such companies were most happy to send me payment, and I issued them a new key…

So, my licensing system was not subscription based, but I did have that option. However, my first key sent to the customer did have a expiry date until such time I received payment. Upon receiving payment, then I would simply issue them a new license key.

So, I was happy when people copied my software. But, the licensing approach was nice, it did keep and force the company name to appear in that application – so, then most over time were rather happy to pay me.

Yes but as stated Azure's achilles heel is it's subscription costs & unkown read/ writes leaving me with an unknown bill not being able to claim back from the customer. Don't want to go subscription based on this first version.

Well, you can host your own SQL server then, right? Then you have fixed and known costs. However, you actually need to answer the following question:

Are they going to be on the same work place LAN/network, or do you want all users to be able to work at any location with just internet and share the same data?

Since if you assuming same business and work location, and can assume a work network (LAN), then you don’t need SQL server, and can use a standard split Access FE (front end) and an accDB for the back end. This works well if you only expect to have about 1-10 users AND ALSO they will be on the same network.

The downloading, updates and even licensing is 100% separate issue from above.


So, the above is CRITICAL and it’s not clear to me which choice you want or need here.

So choice 1)
They are going to be at same work location, and on same workplace network/LAN. If yes, then you probably don’t need SQL server, right? This setup is the most ideal from a support point of view.


Choice 2)
The users of the software have to share data, but some might be at home, some on the road, and some at work. Or they don’t even have a brick and mortar building but all say 3 of them have to work on the same data, but are in different location. This then does mean SQL server, or maybe means terminal services.

So, choice 1 above? Easy, and you don’t need SQL server.

But, choice 2? Well, now you have more complex moving parts, and more of a challenge.

So, VERY but BEYOND critical you nail down which of the above choices you want here.

Thank you for rough numbers, I was thinking of this as an initial ver 2/ 3 to see how it goes & will develop incrementally in difficulty as I go.

The context of above "50" customers is how much time and efforts will it be to setup and have a new customer.


So, I had to create a whole new copy of a database for each new customer (that’s a big pain, right!!!).

If I was to expect a larger customer base, then this approach is not scalable, and the cost and time of each new customer would become a issue over time – something one wants to avoid.

R
Albert