I'm developing a simple database app in visual studio (c# for Windows) using an access backend.
That's all fine until I try to open the database file from within access, when all the reocords get deleted.
Could anyone explain why this is please?
Did you add the database to your solution? Select it and check the Copy Local (aka Copy to Output Directory) setting in the Properties window. Make sure it isn't set to Copy Always,
We need more information. You say that when you open the database from within access, "all the records get deleted". The way the question is phrased implies that some process is running as part of opening the database, e.g., an autoexecute macro. Do you really know that is what is happening? Or are you really just saying that "when I open the database file from access, the records are not there". If the latter, then something is happening along the lines of what cletus suggests.
This is an old question and I don't know if the original poster is still around, but something that didn't occur to me at the time I originally read the question was that perhaps the C# app is using a transaction to insert the data and is not committing it. If that were the case, the data would be visible in the C# app and would not be there when you opened the file in Access. On the other hand, the data wouldn't be there in a new session of the C# app, either, so this might not be the issue.
Related
I was having some trouble bulk-loading records to go faster than what cursor.executemany would allow. I hoped the bulk operations documented with regular MonetDB here might work, so I tried an export as a test. e.g. cursor.execute("COPY SELECT * FROM foo INTO '/file/path.csv'"). This doesn't raise an error unless the file already exists, but the resulting file is always 0 bytes. I tried the same with file STDOUT and it prints nothing.
Are these COPY commands meant to work on the embedded version?
Note: This is my first use of anything related to MonetDB. As a fan of SQLite and a not-super-impressed user of Amazon Redshift, this seemed like a neat project. Not sure if MonetDB/e is the same as MonetDBLite - the former seems more active lately?
Exporting data through a COPY INTO command should be possible in MonetDB/e, yes.
However, this feature is not working currently. I was able to reproduce your problem, i.e. the COPY INTO creates the file where the data should be exported to, but doesn't write the data. This does not happen with regular MonetDB.
Our team is notified of this issue, and we're looking into it. Thanks for the heads up!
PS: Regarding your doubt about MonetDB/e vs MonetDBLite: our team no long develops and maintains MonetDBLite. Both are embedded databases that use MonetDB as the core engine, but MonetDBLite is deprecated. After having learnt some do's and don'ts with MonetDBLite, our team is developing our next generation of embedded databases.
So for your embedded database needs, you should follow what's coming out of our MonetDB/e projects.
I've created a test for it at: https://github.com/MonetDBSolutions/monetdbe-examples/blob/CI/C/copy_into.c
Also filed a bug report over on GitHub: https://github.com/MonetDB/MonetDB/issues/7058
We're currently looking into this issue.
I have written a Windows application in Visual Studio that reads data from a Microsoft Access database. Everything works fine; however, after publishing the application I need it to read the database when the database is changed or updated. Can anyone help with where to put the Access database and how to get the application to look at it when it opens?
It sounds to me like you can place the Microsoft Access (presumably, a single .accdb file) anywhere you want to put it and then--as long as your program knows where that file is--simply use System.IO.FileSystemWatcher.
See this question/answer(s) for more details:
Notification when a file changes?
I am using MS Access 2010 on Windows 7, in a moderately locked down corporate environment. I have developed a report that calls several subreports, and one subform, which in turn has several embedded graphs. The various subentities pull data from multiple queries that build on other queries, some of which are parameterized. The two parameters (Year and Month values) are taken from a single form that includes buttons to preview and print the report. All data tables are local to the .accdb file; there is no server back end.
I developed the file locally, then copied it to a shared network folder and tested. Everything works as expected for me -- the report takes a few seconds to run, as the data work is admittedly a bit clunky, but it still displays in a timely fashion. I am in California, the shared folder is somewhere in the Midwest or South, and my coworker is in Texas. I asked coworker to open the file, enter values in the form, and run the report. He got a warning saying the file was read-only, but the form still ran, but the report locked up. Specifically, the report starts to run, the progress bar moves to about 1/3rd or 2/5ths across, then just stops. There is no error message given.
I had coworker force-close Access, deleted the lock file, gave coworker full permissions on the file, and had him try again. Same results, minus the read-only error. Entering values in the form and running the report directly, rather than using the buttons, gives the same result. I had him go through the other database objects, and all of the tables, base queries, subreports, and subform open "instantly", with the expected data and record counts. For some reason, though, bringing it all together just crashes Access every time.
Coworker was doing a screen share for the initial tests, so I know he was following directions correctly. We tried it without, in case the bandwidth was an issue, with no improvement.
I've tried searching variations on "ms access report locks/freezes/hangs" via Google and SO, and got a bunch of stuff about record-locking, which I think is not the issue here. If anyone can suggest better search terms, I'm game to try them.
The data used is confidential, so I'm reluctant to post code, but can work on sanitized versions if that's necessary for a solution.
Since the file is locked in Read-Only, any calculations that are done which in any way write data to a table are not going to work. I suggest you double check the security permissions the user has to the network folder. That includes both the NTFS security and the shared folder security.
He needs write permission to the entire network folder (not just the database file) because Access will try to create the laccdb file and write to it within the network folder. If he does not have write permissions on that folder access will not be able to edit the laccd file.
I trying to find a SQL script that a former colleague of mine used to run periodically. His instructions are to log onto his machine and go to his recent files and select the file.
He doesnt remember where the file physically exists as every time he runs it he would open the file via this method.
My question is how do I access this list? Problem is we wiped his machine and made a copy of his HD. ive tried navigating to \USERS\Application Data\Microsoft\Microsoft SQL Server\100\Tools\Shell\ but there is nothing obvious I can use here.
Appreciate your comments.
I believe this is tracked in the in the following location (depending on your version of SQL) in the registry
HKEY_CURRENT_USER\Software\Microsoft\SQL Server Management Studio\11.0\FileMRUList
[Edit] On a side note, rather than looking for this recent list I would use a grep tool like textcrawler (free, and awesome) to search for a particular string (presumably you remember some sprocs that are called or tables that are accessed by the script) within all .sql files on the hard disk.
In SSMS version 18, the registry path to the recent file list is:
HKEY_CURRENT_USER\Software\Microsoft\SQL Server Management Studio\18.0_IsoShell\MRUItems{01235aad-8f1b-429f-9d02-61a0101ea275}\Items
Keep in mind, you must restart SSMS for any changes to take effect.
Why does Visual Studio asks (Optionally) to add database .mdf file to be stored in project output folder? It's still is a requirement that .mdf file to be part of running SQL Server instance so that application can work with the database.
For instance if I stop the instance of SQL Server and run the application, it throws exceptions etc. I wonder why it stays in VS solution folders then? Any advantage of this?
I think this is generally to allow for the "User Instance" feature, which lets you make a copy of the MDF file for local debugging purposes (without impacting the database that's running within SQL Server).
You can see this URL for more information on how this feature works, but I would just ignore it, since it is deprecated and in SQL Server 2012 is replaced with a fundamentally better and different way of dealing with isolation and avoiding instance maintenance (no more AttachDbFileName nonsense).
Personally, I think it's much better to work with a single copy of the database, attached to a proper instance of SQL Server, because these other methods just seem far too convoluted and confusing for very little gain. But maybe that's just me.