This is more of a "just wondering" question. Is there any way to access the Windows Indexing service database through ODBC in MS Access or SQL Server? I know there are a million recursive programming ways to traverse the file system but if I was only looking for files with a certain name I would think something as simple as "Select Fullpath from CDrive Where FileName like '%HEVC%'" would be easier and more lightweight than other methods.
I can't seem to Google this since all it does is return a million results for ODBC DSN creation.
Foreword: My focus is on other projects, but this is an interesting topic.
Microsoft uses an EDB file to provide a central Indexing Service - MSDN. Based on the Microsoft SQL Server CE engine, it is lightweight offers a number of methods for access including addition of third party file type definitions.
However, there are differences...significant ones that prevent direct translations of EDB and CEDB. Comparing EDB with SQL Server CE
As I said, there are access methods. The ODBC you were hoping for was discontinued after Windows XP.
However, Microsoft has developed two methods:
Windows Search (client side)
Microsoft Search Server Express (server side)
Both methods allow for quick file searches and likely could be integrated into whatever warehouse architecture you have through APIs, for example. However, there are limitations on methods that the links point out.
I admit I cannot give a full answer since I was learning, too, but hopefully this can point you in the right direction.
Cheers,
Actually, Found something else here:
Querying the Index with Windows Search SQL Syntax
Works like a charm, just have to get used to the special SQL syntax. Works on Windows 10, just having a problem querying a Storage Space. I'll update if I find an answer.
Related
I have a scenario where I get queries on a webservice that need to be executed on a database.
The source for these queries is from a physical device so I cant really change the input to my queries.
I get the queries from the device in MSSQL. Earlier the backend was in SQL Server, so things were pretty straight forward. Queries would come in and get executed as is on the DB.
Now we have migrated to Postgres and we don't have to the option to modify the input data (SQL queries).
What I want to know is. Is there any library that will do this SQL Server/T-SQL translation for me so I can run the SQL Server queries through this and execute the resulting Postgres query on the database. I searched a lot but couldn't find much that would do this. (There are libraries that convert schema from one to another but what I need is to be able to translate SQL Server queries to Postgres on the fly)
I understand there are quite a bit of nuances that will be different between SQL and postgres so a translator will be needed in between. I am open to libraries in any language(that preferably runs on linux : ) ) or if you have any other suggestions on how to go about this would also be welcome.
Thanks!
If I were in your position I would have a look on upgrading your SQL Sever to 2019 ASAP (as of today, you can find on Twitter that the officially supported production ready version is available on request). Then have a look on the Polybase feature they (re)introduced in this version. In short words it allows you to connect your MSSQL instance to other data source (like Postgres) and query the data in as they would be "normal" SQL Server DB (via T-SQL) then in the background your queries will be transformed into the native pgsql and consumed from your real source.
There is not much resources on this product (as 2019 version) yet, but it seems to be one of the most powerful features coming with this release.
This is what BOL is saying about it (unfortunately, it mostly covers the old 2016 version).
There is an excellent, yet very short presentation by Bob Ward (
Principal Architect # Microsoft) he did during SQL Bits 2019 on this topic.
The only thing I can think of that might be worth trying is SQL::Translator. It's a set of Perl modules that have been around for ages but seem to be still maintained. Whether it does what you want will depend on how detailed those queries are.
The no-brainer solution is to keep a SQL Server Express in place and introduce Triggers that call out to the Postgres database.
If this is too heavy, you can look at creating a Tabular Data Stream (TDS is SQL Server network transport) gateway with limited functionality and map each possible incoming query with any parameters to a static Postgres query. This limits any testing to a finite, small, number of cases.
This way, there is no SQL Server, and you have more control than with the trigger option.
If your terminals have a limited dialect demand then this may be practical. Attempting a general translation is very likely to be worth more than the devices cost to replace (unless you have zillions already deployed).
There is an open implementation FreeTDS that you could use if you are happy with C or Java.
Despite a few hiccups and a few workarounds, my MVC based Entity Framework (Code First) application is now complete and ready for deployment.
I originally tried developing through SQL Express, however, I had non stop problems with the Code First approach as I asked about here which made it completely unworkable.
So, in the end, I developed it following the majority of guidelines and used SQL Compact Edition. This has been absolutely brilliant for development - but - now it has come to deployment and I am stuck.
I have seen some people saying about generating the Schema from the .SDF file, however, there are differences and restrictions in Compact edition such as nvarchar being limited to a length of 4000, and I need max in my application.
So basically, what can I do?
In addition - but not essential - , I am going to be moving on to the next project shortly, It will involve heavy usage of items needing to be stored in a database that are longer than 4000 characters. Are there any better strategies now for development / Is it possible to use Code First with SQL Server Express or SQL Full (I have MSDN and willing to install/use anything that will help).
Here are my unofficial recommendations:
SQL CE is not a viable option for most production applications that are based on MVC (although I have used it in production services in rare cases).
I would try to avoid switching databases between development and production - i.e., don't test on SQL CE and deploy to SQL Express or something else.
I have never tried to open an MDF inside of Visual Studio - maybe I'm misunderstanding what you're saying here, but in general I'd recommend using the SQL Server-specific tools to manage databases: http://www.microsoft.com/download/en/search.aspx?q=sql+server+management+studio+express.
Regarding the other post, I would generally discourage using the AttachDBFilename portion of connection strings unless you need it for a specific purpose.
It sounds like you may want to review the available database initialization strategies: http://blog.oneunicorn.com/2011/03/31/configuring-database-initializers-in-a-config-file/.
There are lots of walkthroughs on our blog and the MVC MSDN site - if those don't work for you feel free to reach out to us from our blog and provide feedback on what we can do better!
Our blog: http://blogs.msdn.com/b/adonet/
MVC walkthroughs: http://www.asp.net/mvc/tutorials/getting-started-with-mvc3-part4-cs
On the one hand regarding deployment/migration you might want to take a look at http://exportsqlce.codeplex.com
On the other hand I've been checking Microsoft SQL Server Compact 4.0 Books Online and in principle there is no known issues with data types, although the limitation you mentioned for nvarchar is confirmed.
Finally in order to elaborate a strategy you might find interesting the Differences Between SQL Server Compact and SQL Server
You need to create a debug and a release specific web.config file:
In the release specific file you remove the connection string, so it creates a database for you.
In the debug specific file you keep the connection string.
However, I would suggest you to not use a connection string and use SQL Management Studio instead. Given that the Compact Edition does not support your requirement, this is a good time to switch...
Does anybody know of any good tutorials that show how to configure FluentNhibernate for SQL Server 2005/2008. The ones I have found usually just use SQLite, but I would like to see one that specifically targets SQL Server 2005/2008.
I really liked the sample tutorial on the FluentNhibernate website (http://wiki.fluentnhibernate.org/Getting_started#Your_first_project), but it looks like most tutorials I have found seem to only deal with SQLite. It would be great to see a working tutorial that deals with the more common databases in real world applications like SQL Server 2005/2008, MySQL, etc
Thanks!
Tutorials use SQLite not because it's "quick & dirty" but because it's embedded, small, and free. Anyone can download System.Data.SQLite and start working in about 60 seconds, and later switch (or not) to another database with minimum impact. That's one of the major benefits of using an ORM.
Just in case, I want to clarify that SQLite is not a toy database, for many applications it's enough and even necessary since the characteristics I mentioned above aren't too common for a relational databse.
In the case of fluent-nhibernate, the only difference is that instead of:
Fluently.Configure()
.Database(
SQLiteConfiguration.Standard
.UsingFile("firstProject.db"))...
you'll have:
Fluently.Configure()
.Database(
MsSqlConfiguration.MsSql2005
.ConnectionString("a raw string"))...
Each database engine config has its own specific optional settings.
More information about configuring different databases in the fluent-nhibernate wiki.
I'm having trouble figuring out databases in VB.NET. (VS 2008)
What control(s) do I need to use and how do I use them? I am ,looking for tutorials and sample code too.
I'm working on a trivia game where the admin can remove and add questions to a database.
EDIT:
The program must be able to do all of the DB interactions itself through code.
Regarding DB portability...
I do not intend to install it on many machines, so portability is not a major issue, but I's rather not be bound to Access or SQL Server. (Is that possible? - A portable database file?)
A bit more complaining...
I really need help with connection strings and the whole DB gamut in VB. I've done DBs in PHP so I'm not completely ignorant. It's the VB side of things that's confusing.
Thanks.
Have you considered SQLite DB? It's a very small DB and is used my many vendors. I have not used SQLite personally, but I do know that Firefox uses it and so does iPhone (from what i've read).
SQLite does not require you to install anything (as per the post below). It's a nice alternative to Access or carrying around SQL Server Express.
If you do decide to use SQL Server Express, you will be required to install the run-time, from here for each machine it's used on.
Below are some links which may help you get started
Google for SQLite DB
ADO.NET 2.0 Provider for SQLite
And finally, here's a blog post outlining how to get it done, and quickly.
Cheers!
I would suggest Microsoft's Enterprise Library - The hands on labs available make it a breeze to setup access to a database, and can make it as simple as a config change to point to a new/different DB.
Also, check out http://connectionstrings.com/ for related info.
What is currently the best solution for WPF applications which are meant to be used on one computer where various users log into them and use them to get/save information locally? Here's how I see the options:
MDF would seem to be the best choice since I assume you can lock it down quite well so that even though users can access the .mdf file, they still couldn't access the data in it except through the application itself. I assume the .MDF file would have to exist separately from the application so would deploy the .exe and the .mdf file. Oh, if you use an .MDF file, does the user need SQL Server installed to use it as is indicated in this stackoverflow question?
I would think SDF wouldn't be recommended since it has quite a bit of limitations and used mainly for mobile storage.
XML might be appropriate if security didn't matter, e.g. a small one-user application to save data that locally that he wouldn't secure anyway, and this file would be easily accessed by other applications/websites on the computer.
SQLite might be a choice but from what I know the APIs for .NET for this database aren't that robust yet, are they?
.mdb Access might be a choice if you needed users to also edit/view the data or generate reports with Access.
there is also IsolatedStorage but I believe this has serious limitations, doesn't it, e.g. not able to access it from other applications?
perhaps using a cloud service might be feasible and quite straight-forward nowadays, would have to investigate
Would appreciate any feedback or ideas.
SQL Server Compact edition is also an option - http://www.microsoft.com/Sqlserver/2005/en/us/compact.aspx
Deployment is pretty easy using ClickOnce or by copying the engine dlls to the application directory.
I would choose SQLite. You can get the ADO.NET Compatible driver here:
System.Data.SQLite
I'd say SQLite. It's incredibly light-weight and easy to use, and the API is fine. You could always use DbLinq as ORM.
SQL Server Compact edition is my choice because of the following benefits:
A small runtime library that you can distribute with your app
Compatible with Linq to Sql (search "SqlMetal.exe")
Integrated design experience with Visual Studio 2008
It's a nice all rounder as a lightweight solution for a .NET app.
http://www.microsoft.com/Sqlserver/2008/en/us/compact.aspx
MDF does seem to be the most flexible solution but user need to have SQL server express installed to use it.
How do you plan on executing CRUD processes? If you are wanting to use Linq to SQL you are kinda limited offically it only supports SQL 2005, Sql 2008 and Sql Compact.
Also, does the application need to be disconnect, partially, fully connected to the internet? That may put some weight on your decision.
IMO, I would start with SQL Server Compact edition and if that was too limiting move to sql server express. (.MDF)