How to access the same database file between two projects in a Visual Studio Solution?

[amorosik]

....MAUI turn on my phone so you can read the .accdb?

@prabha_friend could stop this stupid discussion by actually defining his task.

He didn't ask how to turn on the phone with Maui, but how to read an mdb/accdb file from an app on the phone
And the discussion is far from stupid, but it's very interesting for all Access users who have a smartphone

 

[The_Doc_Man]

From a protocol viewpoint, I think there might be an issue of practicality. This is one man's opinion and if something has changed regarding Access network behavior, it's new to me.

Regardless of how you attempt to encapsulate network traffic, and if we are talking about "real" Access, there is a layer - no matter HOW deeply you encapsulate it - that must be a channel suitable for SMB network exchanges.

IF the app is a stand-alone (i.e. not split) app file, it might be POSSIBLE to create an environment suitable to run Access. If the connection is purely internal, network continuity is trivial via the phone's network stack's LOOPBACK connection at address 127.0.0.1, which every internal network active member will have.

IF the app is split with the FE on the phone and some other DB engine as the BE, all of the protocols I know require a formal connection environment because in the TCP vs. UDP dichotomy of network protocol styles, Access stays on the TCP side of the environment. Phones can and will sometimes be in a "no bars" area, which means the phone has experienced a "network drop" - which will pretty much kill any remotely linked session. The FE would crash. The BE would be subject to the ills of a crashed FE that might have had a pending operation.

IF the app is split and the BE is on the phone, the same rules apply as having the FE on the phone, because a network drop is symmetrical. A drop on one end corresponds to a drop on the other end.

If you have a situation with a UDP-class listener that is web-capable on the phone, AND you have some kind of app that you can launch that will translate UDP traffic into TCP traffic, you might get away with it until something times out and drops connections. A dropped connection will always be really bad for Access-based apps. "Bad" in this case would be a matter of kind, not a matter of degree.

Even for CITRIX connections which isolates the Access SMB traffic, if the CITRIX connection drops, you still have a hung instance that will eventually have to be shut down. In essence, that deferred shutdown delays the inevitable problem of a potentially incomplete update from a lost thread.

Let me say I am skeptical of making this work smoothly and reliably.

 

[prabha_friend]

From a protocol viewpoint, I think there might be an issue of practicality. This is one man's opinion and if something has changed regarding Access network behavior, it's new to me.

Regardless of how you attempt to encapsulate network traffic, and if we are talking about "real" Access, there is a layer - no matter HOW deeply you encapsulate it - that must be a channel suitable for SMB network exchanges.

IF the app is a stand-alone (i.e. not split) app file, it might be POSSIBLE to create an environment suitable to run Access. If the connection is purely internal, network continuity is trivial via the phone's network stack's LOOPBACK connection at address 127.0.0.1, which every internal network active member will have.

IF the app is split with the FE on the phone and some other DB engine as the BE, all of the protocols I know require a formal connection environment because in the TCP vs. UDP dichotomy of network protocol styles, Access stays on the TCP side of the environment. Phones can and will sometimes be in a "no bars" area, which means the phone has experienced a "network drop" - which will pretty much kill any remotely linked session. The FE would crash. The BE would be subject to the ills of a crashed FE that might have had a pending operation.

IF the app is split and the BE is on the phone, the same rules apply as having the FE on the phone, because a network drop is symmetrical. A drop on one end corresponds to a drop on the other end.

If you have a situation with a UDP-class listener that is web-capable on the phone, AND you have some kind of app that you can launch that will translate UDP traffic into TCP traffic, you might get away with it until something times out and drops connections. A dropped connection will always be really bad for Access-based apps. "Bad" in this case would be a matter of kind, not a matter of degree.

Even for CITRIX connections which isolates the Access SMB traffic, if the CITRIX connection drops, you still have a hung instance that will eventually have to be shut down. In essence, that deferred shutdown delays the inevitable problem of a potentially incomplete update from a lost thread.

Let me say I am skeptical of making this work smoothly and reliably.

There is no context(dbcontext) available for accdb. Otherwise its just an another file format.

 

[AccessBlaster]

I worked with a guy who was able to get Excel spreadsheets to work on a smartphone for light inventory purposes. I understand that Microsoft Access is a completely different animal.

 

[prabha_friend]

I worked with a guy who was able to get Excel spreadsheets to work on a smartphone for light inventory purposes. I understand that Microsoft Access is a completely different animal.

Can be domesticated: https://www.nuget.org/packages/entityframeworkcore.jet/

 

[The_Doc_Man]

If you are treating the file of type .ACCDB as "just another file format" there is the problem that you have to scrupulously honor the file's structure as immutable. I.e. it has to be READ-ONLY, unless you have some sort of library that knows how to deal with Access format. Any attempt to write back to the file that attempts to lengthen any string element by as little as one byte will probably make the file unusable by Access. Not to mention that unless the targeted file was compacted and repaired immediately before being made available to this alternate environment, you will also have deleted records intermingled with valid (current) records.

 

[The_Doc_Man]

I worked with a guy who was able to get Excel spreadsheets to work on a smartphone for light inventory purposes. I understand that Microsoft Access is a completely different animal.

Excel doesn't use the SMB protocol and has different file characteristics. Also different file locking characteristics.

 

[prabha_friend]

There are people in this world who has done, doing and does so many great things. I know I cannot do the following but just asking:
"If at all I want to build something which make an accdb to be readable and writable in all OS (Windows, Linux, Android and Tizen) where should I start?"
"The people who are crazy enough to think they can change the world are the ones who do." - Sometimes I wanna

 

[AccessBlaster]

Excel doesn't use the SMB protocol and has different file characteristics. Also different file locking characteristics.

True, I might be easily impressed, it was like magic to me 20 years ago.

 

[The_Doc_Man]

There are people in this world who has done, doing and does so many great things. I know I cannot do the following but just asking:
"If at all I want to build something which make an accdb to be readable and writable in all OS (Windows, Linux, Android and Tizen) where should I start?"
"The people who are crazy enough to think they can change the world are the ones who do." - Sometimes I wanna

The problem is "Access", not "database." Because of the database being built using 30-year-old SMB protocols and concepts, you have structural constraints. In a way, it is these constraints that cause network IT guys to sometimes hate Access despite its advantageous features.

I don't know what Xenforo uses but you KNOW it has to be based on a database engine of some kind, and it works with Windows, UNIX, Android, and other clients in other operating systems, and all you need is a web browser. We know that a web-based database DOES work. The problem isn't about databases, it is about Access databases specifically and narrowly considered.

As much as I really enjoy Access databases, I have seen other DBs internally (ShareBase, for example) and the internal layout of those databases is well documented. It is the proprietary DBs that try to capture their audience (literally make them a captive audience) that are the tough nuts to crack.