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

[amorosik]

I've linked to a post that provides a solution
That link also contains an example (source code) of a program that uses the UcanAccess library
So if you write "..yet you refused to elaborate.." you should know you're writing something untrue
Why?

 

[Pat Hartman]

Sorry, I missed the link. "this" wasn't highlighted so it looked like there was no link.

 

[Pat Hartman]

OK. I looked at the link. How will the calling app locate the phone to make the connection assuming this is what @prabha_friend wants to do? Why anyone would store a live, shared BE on a phone is beyond me though. And because this tool does not support file sharing, what are other clients supposed to do while someone else has the BE opened exclusive?

 

[Edgar_]

I'd create a web API that both projects can access and be done with it.

If an .accdb file is what I must use, then I'd put the file in a Windows server. That way, if either of the projects sends an HTTP request, the server simply connects to the .accdb file, does its business and returns what you asked for.

If a sqlite database is to be used, same thing, but the server could be whatever, not necessarily Windows.

 

[amorosik]

... is beyond me though....

You're not the one who has to think about how the system should be set up
The colleague asked some questions; if you know the answer, you can help him
Otherwise, save the ink

 

[amorosik]

Sorry, I missed the link....

Yes, okay, you're excused

 

[prabha_friend]

Sorry Doc. Now only I searched about accdb and visual studio. We cannot migrate accdbs using Entity Framework Core. so now my question is: "How to use an sqlite3 database file between two projects inside a visual studio solution". Now it has become a complete "Other Software". Thanks Doc.

_dbContext.Database.EnsureCreated() does the Magic!

 

[Pat Hartman]

@prabha_friend Please clarify. Are you storing the BE on a phone or are you trying to access the BE from a phone?

 

[prabha_friend]

@prabha_friend Please clarify. Are you storing the BE on a phone or are you trying to access the BE from a phone?

Both storing and accessing the Backend in the Phone itself. Using MAUI, you can write a single app which can run in windows, android, iphone and Tizen.

 

[Pat Hartman]

Both storing and accessing the Backend in the Phone itself. Using MAUI, you can write a single app which can run in windows, android, iphone and Tizen.

So you're saying that MAUI can make Access run on your phone? I doubt it. If you can use a browser to get to a Citrix server or remote desktop, you can run Access "from your phone" but not "on your phone".

Why are you storing Access databases on a phone anyway? And why would you want to retrieve data from an Access database on MY phone and how are you going to turn on MY phone anyway?

 

[prabha_friend]

So you're saying that MAUI can make Access run on your phone? I doubt it. If you can use a browser to get to a Citrix server or remote desktop, you can run Access "from your phone" but not "on your phone".

Why are you storing Access databases on a phone anyway? And why would you want to retrieve data from an Access database on MY phone and how are you going to turn on MY phone anyway?

https://www.access-programmers.co.u...-a-visual-studio-solution.334325/post-1968280

 

[amorosik]

So you're saying that MAUI can make Access run on your phone?

No
He asked how to read an Access data file
Not how to run Access on his phone.

 

[Pat Hartman]

Both storing and accessing the Backend in the Phone itself. Using MAUI, you can write a single app which can run in windows, android, iphone and Tizen.

Not an Access app. And HOW does MAUI turn on my phone so you can read the .accdb?

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

 

[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.