I am creating a SQLite3 database and would like to know if it possible to create a report view similar to Microsoft Access? If this is possible, could someone answer with some resources I could review to learn how?
SQLLite does not have reports. It's just a database engine. Though many people use the term "database" colloquially to cover a user interface + reports for accessing data, that is not what is generally meant by technical folks. Typically databases are just a means for storing and retrieving data in a more raw format, and user interfaces and report engines are in a separate layer of software.
There are many reporting engines out there, and Stack Overflow isn't a forum that specializes in software recommendations, but if you do a search specifically for reporting engines that can connect to SQLLite, you may find something you're looking for.
Related
Is it possible to link to a Business Objects Universe in R?
I can connect R to a SQL database but that doesn't give me the Universe where all the joins are already created. I have end users that currently get there data through Business Objects but R would better suit their needs. And, since they are already familiar with field names and how the tables are linked in Business Objects, I would like for them to just link R to the existing BOBj universe.
Thanks!
Since I'm not allowed to recommend specific software (new to me, but fair is fair :)) I'll just mention two options:
1) search the internet for software that gives odbc access to business objects universes. These are good keywords on my favorite search engine: 'odbc leverages SAP BusinessObjects Security'
It has the distinct advantage of making sure that all user access is being governed by business objects, but data will have to travel through that server, and you will need to pay for licenses to SAP as well as the vendor of the new odbc...
2) give the users in question ODBC access to the same tables that the BO reports/universe run against, and make sure they are allowed to see the SQL in their dataproviders. Then tell them to 'cook up a report, and the copy&paste the SQL to R'
Option two may save you some licenses and give you better performance, but I would personally go for option 1) :)
I have one issue. Actually we have one spring-mvc web based application , for which we want report generation mechanism. I came across Talend ETL. Can anyone tell whether to use talend as report generation mechanism will be fruitful. Can i integrate it with my application ? Or whether i should search for some jar that can help in fast report generation mechanism.
Thanks
The question is vague, but let me try to answer anyway. Talend is not a reporting platform, but an ETL (read: data handling and transformation) tool.
You can embed a TOS job in your application, and it'sadvisable to do if you need to handle data in a medium/complex way without reinventing the wheel (ie. read an Excel file, do some things, save on DB...). But use it as reporting or data visualization platform would be a pain in the neck.
There're better embeddable solutions for these duties. Birt and JasperReports come in mind, but there's plenty of them. The real question for choosing from is: do you need a low-level reporting service, not much more than a framework at the end of the day, or a polished, maybe client-server, solution to query as a service?
We have an ASP.NET app with SQL Server & it is a photo & video sharing site.
Details of photos and videos are stored in tables & the files are in the file system.
Database has 75 tables and 225 stored procedures. The app will be ready for production deployment within next 6 months.
Due to longer time growth concerns, we decided to switch to NoSQL (MongoDB) database.
We have few questions regarding the best way to approach this:
Is it better to deploy the app with SQL Server backend and migrate to NoSQL later?
OR re-architecture now and rewrite/recreate database, tables, procedures and data layer
How difficult will it be re-architecture/recode with MongoDB? Any tools or BKMs?
EDIT:
Our app is Youtube+Flickr type site where user will share photos and videos with lots of comments, tags and ratings (photo\video & comments).
Is NoSQL a better database to move to? Reason for moving: cost + read query speed
Please help me with you valuable advise.
Thank you very much.
Change is always exponentially more expensive the later it is introduced to a project. This is a core principle of software engineering. You should do this now.
That said, I question your long-term vision. Relational databases, used properly, have a lot of performance in them.
This question raises more questions than answers.
Have you benchmarked your current implementation in terms of requests/responses?
Why MongoDB out of all possible NoSQL databases? (Don't get me wrong, I love Mongo, but love and hype should not weigh in technology choices)
Are you certain you will get the large userbase you're expecting? Why are you so certain?
Using stored procs seems to tip off that you aren't using an ORM? Why not?
Generally, I'm against these types of re-architectures. Firstly, you need to get your whole team acclimated to how Mongo affects development. Secondly, your ops team needs to get acclimated to how to deploy and maintain a Mongo installation. More likely than not, this will prevent you from launching in a timeline you want to launch.
I'd say that you should probably launch as is, fix the ORM part if you aren't using one, benchmark your app, benchmark a prototype of your app backed by Mongo and if the performance advantages are so big that it warrants the pain of re-architecture do it.
To your latter question, there aren't any tools right now, as far as I can tell, that'll automate or semi-automate the database import/export from SQL Server to Mongo. There are barely tools to do that for MySQL.
I've done such a migration a few month ago, during the early developement stage of a website in ASP.NET. It was a hard decision, but I could concentrate on that migration. The reason why I did this migration was the ORM that I couldn't trust anymore and some very slow queries that I had no idea how to optimize.
During coding phase, what I figured out was : I was spending a lot of time with the data model in SQL Server (using Entity) and all the plumbery code.
Now, no more store procedures (C# and Linq code instead), no more 2 layers to maintain (the code is the model).
My small experience says : The earlier the better but don't get me wrong, before migrating you really have to think in Document rather than in RDBMS. This means you may have to partially change the businness DataModel to correctly utilize MongoDB features, otherwise you could get bad performances and Mongo DB is useless for bad models.
Another point is the admin stuff. You'll have to quickly learn Mongo DB admin to be up to speed. And even if the tools are good, they completely differ from SQL Server tools.
In conclusion, If you're convinced MongoDB is your future data store and search database,
(and it was in my case), read documentation, take time to do some Proof Of Concept. Then you can think Document and load test you new model.
Your core question appears to be whether to make the switch to MongoDB now, or deploy on SQL and go to MongoDB in a future release.
You do not appear to be using an ORM (e.g. NHibernate, Entity Framework.) Setting other concerns aside, if you're convinced that you want to go to NoSQL, then I would do it now rather than later. Unless you integrate a Provider model for your data access, changing the underlying data access strategy after it is already established would be difficult.
I agree. Switching now is better, if only to avoid the data migration headache switching post-deployment will require.
I don't know how authoritative this is but I found this:
http://www.sqlite.org/cvstrac/wiki?p=PerformanceConsiderations
and it doesn't seem good to have a lot of connections to sqlite. This seems to be bad for the web and most applications that have more than a few users. I'm having a hard time thinking of what sqlite would be used for when you don't need that many connections. Every program I can think of needs users, lots of them sometimes, so what would I use a database for that doesn't allow that many connections? I thought about prototypes but why would I use that when I can just connect to a larger database? Embedded apps maybe?
Thank you.
EDIT: Thanks everyone. I look at the page recommended below but an confused about something:
Under appropriate uses for sqlite it has:
Situations Where SQLite Works Well
•Websites
SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). The amount of web traffic that SQLite can handle depends, of course, on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.
Situations Where Another RDBMS May Work Better
•Client/Server Applications
If you have many client programs accessing a common database over a network, you should consider using a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, the file locking logic of many network filesystems implementation contains bugs (on both Unix and Windows). If file locking does not work like it should, it might be possible for two or more client programs to modify the same part of the same database at the same time, resulting in database corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.
A good rule of thumb is that you should avoid using SQLite in situations where the same database will be accessed simultaneously from many computers over a network filesystem.
The Question:
I'm going to show my ignorance here but what is the difference between these two?
This is answered well by sqlite itself : Appropriate use of sqlite
Another way to look at SQLite is this:
SQLite is not designed to replace Oracle. It is designed to replace fopen().
It's good for situations where you don't have access to a "real" database and still want the power of a relational db. For example, Firefox stores a bunch of information about your settings/history/etc in an SQLite database. You can't expect everyone that runs firefox to have MySQL or postgre installed on their machine.
It's also perfectly capable of running relatively-low traffic, read-heavy websites. The performance of it is overall very good, it's more than the large majority of websites need for their traffic levels.
It's often used for embedded applications.
It can be very handy to use a database like storage when you have no access to a database service. So SQLite is used since it's just a file you store somewhere.
I also find that using SQLite is good for getting a prototype application together pretty quickly without the overhead of having a seperate DB server or bogging a development environment with an instance of MySQL/Oracle/Whatever.
Also easy to pick up and move the database to a different machine if you need to.
The iPhone uses it for call history, SMS messages, contacts, and other type of data. Like Ólafur Waage said, good for embedded applications on mobile device because it's lightweight. I have used it also on stand alone applications. Easy to use and available on most platforms.
Think about simple client or desktop apps that could make use of a db, like as a poor example, an address book. Rather than bundling a huge db engine like mysql or postgre with your deliverable, sqlite is very lightweight and easy to include with your finished app.
This FLOSS Weekly podcast episode talks with the creator of SQLite and covers among other things goes over the type of things you would use it for. Everything from file systems for mobile phones to smallish web sites.
In the simplest terms, SQLite is a public-domain software package that provides a
relational database management system, or RDBMS. Relational database systems are
used to store user-defined records in large tables. In addition to data storage and management,
a database engine can process complex query commands that combine data
from multiple tables to generate reports and data summaries. Other popular RDBMS
products include Oracle Database, IBM’s DB2, and Microsoft’s SQL Server on the
commercial side, with MySQL and PostgreSQL being popular open source products.
The “Lite” in SQLite does not refer to its capabilities. Rather, SQLite is lightweight
when it comes to setup complexity, administrative overhead, and resource usage.
For detail info and solution about SQLite visit the link below:
http://blog.developeronhire.com/what-is-sqlite-sqlite/
Thank you.
What the above two answers say. Expanding slightly on Chad Birch's answer, its teh calls to the SQLite db, and a rather poor implementation of sync() that causes FF3 to be so slow in linux.
Is it possible to query the Crystal CMS database and get meaningful data back? The data appears to be encrypted.
I am running Business Objects Crystal Report Server version 11.5
Actually what I discovered I needed to do was use the administration tools available from the Administration Launchpad. I was not responsible for installing Crystal and did not even realise this existed. The query builder and also the "Report Datasources" feature that were available from here was exactly what I needed.
Use the Query Builder tool to query the CMS: http://[server]/businessobjects/enterprise115/WebTools/websamples/query/. For more information about the query language, see http://devlibrary.businessobjects.com/businessobjectsxi/en/en/BOE_SDK/boesdk_dotNet_doc/doc/boesdk_net_doc/html/QueryLanguageReference.html#2146566.
The properties that are returned by this query are store in a serialized state (I'm guessing binary and encrypted) in the Properties field in the infoobject database table (I can't remember the actual name of the table).
I had a similar problem on my workstation at the office. It sounds like you need to reinstall (that's what worked for me). This is a known bug according BussinessObjects (I had to call them and use our maintenance support). Hopefully you can find more information by searching for, 'Crystal Business query corruption' instead of calling them if the reinstall doesn't work for you.
They told me the data is not encrypted, but occasionally components don't install correctly and the queries come back in a binary form that is all garbled.
Good luck!
There are also several third party solutions out there that naturally layer "on top of" the CMS or Central Management Server to abstract the proprietary storage format into human-readable form. We develop a native database driver to the CMS which can be found at http://www.infolytik.com/products.
full disclosure: I'm the main developer and founder of Infolytik.
My experience is that the data is not encrypted but that it is not really readable. Your best option is to use the Auditor Universes to build you some reports. You can also check out the SQL that the auditor Universes are uses as a baseline for constructing additional reporting.