We have MITEL MiVoice Business as our office phone system and we have default reports that come with it. I have access to the Mitel SQL database and have created a few custom reports from that database using SQL Server. Currently, I have been tasked with creating a report to show the IVR Statistics but I can't seem to find any table that has specific fields relating to the IVR information.
Does anyone know which tables in the Mitel Database can be used to pull up the IVR stats?
I'm looking to create a report which gives data like the number of times the system hung up, the user hung up, number of times they were transferred to the agent, any payments made through the IVR system, etc.
Related
I've written a Crystal report that primarily works from a temporarily MDB file that is created on the fly in an Application (which I do not have access to source code for).
I need additional data, so I linked to a secondary MSSQL database where I store more information.
I was able to add tables from this SQL database to my report, and link to them with no trouble. But when I try to include views in this same SQL database in this report, I get a "Logon Error".
My first thought was that is is a permission issue, but I haven't set permissions for specific tables and views in this database, only permissions to the entire database.
Frustratingly, I don't see any errors in the SQL logs for the database.
Does anyone have ideas on what I can check to get this fixed?
Just To Clarify: I can see these views in the Crystal Report, and I can add them, add fields to the report, and create links. I can even Browse Data in fields within the view in Crystal. It's only when running these reports from the 3rd party application that I get an error.
Is SQL Server set to use NT Authentication? If so, the 3rd-party application is probably running under a user context that doesn't have permissions.
I have a large Oracle source database with many objects and wish to migrate a comparatively small set of table definitions to a SQL Server instance using Microsoft's dedicated migration tool SSMA. I ran the migration tool previously, having to leave it processing overnight due to the quantity of objects. When I tried to save the project, frustratingly, the machine ran out of memory, taking me back to where I started.
I initially connected as SYSTEM, so created a new user that could select only from the tables for migration, along with CREATE SESSION and CONNECT privileges. This failed on connection to Oracle due to the dictionary tables being inaccessible.
I then added granted SELECT ON ANY DICTIONARY to the new user and connected to the Oracle source. This time, the connection was successful, but I believe the entire dictionary is being read due to the amount of time it's already taken to load the objects into SSMA.
What I would like to know is: is there an easy way to constrain the set of tables being loaded into SSMA, with the intention of speeding up the connection process?
I have a mini account software. In this software I can store multiple company data. The data is stored in SQL Server 2008 R2 database.
In current database I have a User table which stores all user names, a Company Master table which stores company details like name,address, session etc. and user ID as FK with user table. Next is tran table which link with company Master and stores vouchers details and others table link to tran tabel like bill, payment etc.
The app is build for small companies and professionals who keep & maintain there their client data. In that scenario all data is separate and mutually independedent. In case of the small company they maintain all subsidiary company's account related data in a single app. Some time they receipt or send any one subsidiary company data to that company or any government body or Audit firms. like mobile phone contacts, I can send all contacts or any selected contact.
Users used to select his/her company first form company Master and then add/edit reference data or view report on the basis of selected company ID.
Now my problem is the data volume is become very high on some client places because of 50 to 60 companies data are stored in a single database and how I get company ID wise backup or restore the data. Is filegroup of sql server can help on this matter? I have no knowledge of filegroup.
Please help me.
Do not split your SQL database into multiple SQL databases (either do not create more filegroups etc.) just because you need to get data filtered by the CompanyId. Everytime when your Client would need to create a new Company, your application would have to create a new database for it. This would also quite complicate things like app updates.
If you do not face any grave performance problems - like when using SQL Express and your client database is 9 GB (max. database size for Express is 10 GB) - leave 1 database for 1 client.
Be sure all your related tables are well indexed by the CompanyID column. Then you can provide means to export data by CompanyID from your application - custom reports, exports to csv files, Excel etc.
Database backup file is usually not used for passing data to other applications. Its goal is to assure disaster recovery - when the disk fails etc. then your client will be able to recover easily. On contrary when he would have 50 database files in place of just 1 he would have hard time restoring all those databases properly.
Supposing we have a web application, which uses a SQL Server 2005 server database, would it be better for performance to move all our custom Log tables to a specific catalog?
Scenario
Our web application today uses different catalogs from SQL Server. Each catalog have tables related to a problem (domain/subject): db_financial, db_corporative, etc.
These catalogs already have many different log tables, to register a history of changes made by users during application usage: tb_log_product, tb_log_customer, tb_log_provider_prices, etc.
The goal
The goal is to know if there is any advantage on moving log tables to a specific catalog.
These log tables can have lots of data, so I was wandering if it is a nice idea to move all of them to a different catalog such as db_log (or if I must keep the log tables in the catalogs they are now).
Logs are mostly used for auditing purposes and to keep history of what-happened and who-dun-it. If you have a database called db_operations and table such as tb_customer, I recommend that your log-table tb_log_customer be in the same database (db_operations).
Keeping them in the same database will allow you to take backups of both customer and customer-log table as a single unit of work. If your log was in a different database such as db_logs, you would have to back up db_operations and db_logs at the same time and still not get a pristine restore. Same issue applies to log shipping and mirroring techniques.
To manage the log tables, I'd recommend creating filegroup(s). Log tables can go on these filegroup(s) and the path for the filegroup can be a different volume/controller. To manage the size of the log files, I propose deleting history after a certain period of time. I'd recommend taking a look at partitioning as well.
Background
I have a production SQL Server 2005 server to which 4 different applications connect and make changes.
There are no foreign keys and in some cases no primary keys.
Unfortunately throwing the whole thing out and starting from scratch is not an option.
So my solution is to start migrating each of the applications to a service layer approach so that there is only one application directly connecting to the database.
However there are problems that need to be fixed before that service layer is written and all the applications are migrated over.
So rather than make changes and hope they don't break any one of the 4 badly written applications (with no way of quickly testing all functionality) my solution is to start auditing the database
Problem
How do I audit what stored procedures, tables, columns, views are being accessed/updated/called by each user on SQL Server 2005.
I can find out which tables are being updated but I have no idea which columns and by what users.
I also don't know if certain tables are being accessed only through stored procedures/views.
I know that SQL Server 2008 has better auditing features but if I could do this without spending money that would be great. That said if the best solution is to upgrade or buy software that's also an option.
Check out SQL Server 2008's CDC feature. You can't use this directly in 2005 but you can write a trigger for each table to log all data changes to a new audit table. i.e. you'd have an audit table for each table in your db, with all the same columns plus some additional columns saying what the operation was and when it occurred.
If the nature of your applications means you can get user information and/or application information from CURRENT_USER and APP_NAME() you could include that information in the audit table too.
And check out this answer for more goodness.