Future of Access (5 Viewers)

[Pat Hartman]

All development environments have the same problem if you release without proper testing.

I agree but usually the bad module doesn't affect other parts of the application as it can with Access.

Having source control is excellent, especially when working with a team. Since I generally work alone, I am religious about backups and I use export to text to prevent backing up corrupted versions of the database.

 

[RonPaii]

I agree but usually the bad module doesn't affect other parts of the application as it can with Access.

I agree but usually the bad module doesn't affect other parts of the application as it can with Access.

Having source control is excellent, especially when working with a team. Since I generally work alone, I am religious about backups and I use export to text to prevent backing up corrupted versions of the database.

I don't understand why you are treating errors in an Access module any different then any other environment. If I make a breaking change in a c# class, any other class importing and using the class will have a problem. The problem with Access and VBA is the limited IDE and the resulting difficulty of using modern development process. I can shoot my self in the foot just as easily with C# and VBA.

 

[Pat Hartman]

I don't understand why you are treating errors in an Access module any different then any other environment.

It seems that I cannot explain it so you understand the problem.

 

[RonPaii]

It seems that I cannot explain it so you understand the problem.

Maybe were are talking past each other but once I started using joyfullservice for export and build and Git for source control, I started looking at the ACCDB FE more like a DLL. I can fork the source in GET to try a something new. If a change to the production FE is need before the fork is done, I can restore that version, make the change, test, release the go back to the fork and import those change or when the fork is done I can merge with the main to include changes made to the main. The ACCDB or ACCDE is just a release, GIT has the source with each object in it own file(s). BTW I also generally work alone.

 

[BlueSpruce]

The problem with Access and VBA is the limited IDE and the resulting difficulty of using modern development process. I can shoot my self in the foot just as easily with C# and VBA

I thought Visual Studio was more versatile than Access' IDE? Even if vba code modules were stored externally in Windows files, you still have to compile, link and load the object files, and runtime errors can still happen even though the modules compiled.

 

[RonPaii]

I thought Visual Studio was more versatile than Access' IDE? Even if vba code modules were stored externally in Windows files, you still have to compile, link and load the object files, and runtime errors can still happen even though the modules compiled.

I not using Visual Studio for VBA. The programing is done in the ACCDB, the add-on is used to export changes and if I need to import from GET or roll back, builds that source into a new ACCDB which is then compiled like normal. The joyfullservice add-on is not source control, GET handles that. It is the interface and builder.

 

[BlueSpruce]

I not using Visual Studio for VBA. The programing is done in the ACCDB

I kno that. I was referring to the C# you mentioned. It's a lot easier for a team to work with external code modules versus code encapsulated in accdb containers.

 

[The_Doc_Man]

And then there's this:
View attachment 121153

Regarding this post:

I was catching up on this thread and ran across this post. Specifically to the comment in the post regarding a lost ODBC connection, there is a reason for that problem. We start with the fact that network traffic generally breaks down into UDP and TCP families. ODBC is a member of the TCP family of protocols - one of many. UDP is generally used for "connectionless" protocols most commonly used with web sites. TCP usually involves "sessions" or persistent logical connections between the participants, often called Sockets.

At least 20 years ago there was a security directive regarding network options configuration. Short answer: The ability to RECONNECT to a TCP-family session was determined by the U.S. Dept. of Defense to be too big of a security risk.

The reason is because if someone was monitoring a particular military network and was using a Sniffer or other network real-time analyzer tool, and if that network died for a moment, the sniffer had enough information to take over the socket while the network was in flux. Basically, all you need is found in the packet header, including the socket ID, session ID, and connection sequence number provided by the prior network partner. That is, you don't need login-level credentials to do a RECONNECT because that login occurred previously and established the session-layer structure needed for the transactions.

The "very strong recommendation" was therefore disseminated that we should edit all of our network config files to ALWAYS contain "RECONNECT=NO" from that time on. For what it is worth, the SMB protocol used by Access is another member of the TCP family and is another reason why Access is so sensitive regarding network drops.

 

[RonPaii]

I kno that. I was referring to the C# you mentioned. It's a lot easier for a team to work with external code modules versus code encapsulated in accdb containers.

Each team member work on their own copy of the FE and pushing out changes just like an IDE like .NET. Each export only exports the changed objects, not the entire FE. Commits are small and often.

One problem with Access is it's tendency to update all named objects with the same name if you change the case of any 1. This causes more objects to be exported with only case changes which can confuse a merge. To combat this I changed my naming convention for ALL named objects to Pascal Case SomeVariable, were before functions and properties were Pascal Case and variables and parameters were Camel Case someVariable.

For Example if add a function with a local variable userInput then export, only that module is exported. Then in another module I add another function with a local variable UserInput, the first variable is changed. On the next export both modules will be exported even though logically the 1st module has not changed.

 

[BlueSpruce]

The reason is because if someone was monitoring a particular military network and was using a Sniffer or other network real-time analyzer tool, and if that network died for a moment, the sniffer had enough information to take over the socket while the network was in flux. Basically, all you need is found in the packet header, including the socket ID, session ID, and connection sequence number provided by the prior network partner. That is, you don't need login-level credentials to do a RECONNECT because that login occurred previously and established the session-layer structure needed for the transactions. The "very strong recommendation" was therefore disseminated that we should edit all of our network config files to ALWAYS contain "RECONNECT=NO" from that time on.

And for the above reason is why ODBC always requires login when re-connecting to a db server?

For what it is worth, the SMB protocol used by Access is another member of the TCP family and is another reason why Access is so sensitive regarding network drops.

In a previous post I mentioned that Access' file server architecture and SMB are part of the reason why Access is intolerant to network noise and latency, but I was told SMB was irrelevant. We use Samba, which is based on SMB 3.0, for on premise Linux based db server connections with Access FE's on Windows workstations, and have not experienced any connection issues. All workstations have Gigabit network cards and we only use Cat8 shielded ethernet cables, so that also helps to minimize disruptions. However, fault tolerancy should be provided for Access FE WAN connections.