We have a core application that allows for ODBC connections. Currently I use MS Excel or Access to create reports. Many times per week I print them to .PDFs and email them to managers (not all managers have access to our core application). We have Google Apps and I was wondering if anyone had any experience connecting ODBC with GAS. I like to think my process could be better automated.
I also have databases that I have made available to users through Excel for dynamic reporting. I was wondering if I could migrate that to the GAS environment, also.
Any help or guidance would be greatly appreciated.
You could use JDBC to connect to the underlying database and then create your reports and other data manipulation in GAS.
See link for documentation\examples: https://developers.google.com/apps-script/jdbc
Related
Good Afternoon at GMT +8
I have to deploy a project using ASP.net to create a online payslip viewer. the problem is, our network would not host the web app, it would be from a different network, which would be a web host.
My problem is the database, to view your payslip, you should have access to your database, and my answer is replication.
However, my constraint to this approach is we use SQL server 2000 as our DBMS. as i have read in this article
http://msdn.microsoft.com/en-us/library/ms151763%28v=sql.105%29.aspx
the instance was tagged under SQL server 2008, could there be a way to replicate using SQL SERVER 2000? or are there any more ways that i could view data from our database online? without any direct link to our network?
I would also like to know if there would be another approch in regards to creating a simple payslip viewer online.
thanks!
There are several options here:
If you can move your database to that other server that would be an ideal solution.
Can you connect to your database server from external network? How about some kind of VPN? If speed is the problem then this might not work.
Other solutions could be creating another database in your host environment where application would be deployed and use one of many database comparison tools to synchronize the data between two databases but this is far from ideal especially if your application writes/update a lot of data.
One more thing you can consider is creating some kind of web service that you can use to communicate to your database. In that case you wouldn’t need secondary DB.
currently I am writing a Windows 8 App with Sqlite as a database. I want to give the user the ability to view his data in every instance of the app on any device. Usually this problem could be easily solved by using a online database like Windows Azure. But this is not an option in my case.
Is it a good idea to use Microsoft's free service "Skydrive" as a platform to synchronize database files among several devices? Does somebody know any open source projects or blogs that are dealing with this problem that could save me some time for writing the necessary code?
If it's a bad idea, which other options are there that I could use. I want to keep Sqlite as the database for my App.
I am glad to get any kind of feedback or links to resources that might help me.
Best regards
Philipp
imo it isn't a good idea cause the access to db files is to easy. Ofc you can say that access to database files is easy cause you need to just know the app data path to package of your app but still it`s much more difficult than just opening skydrive. And think what would happen if someone would make this directory on skydrive as public.
I would combine local db and online db. Online db as a service for synchronizing data and local db for normal work.
The current application is a kind of CRM application built upon MS Access. The application is for internal use. My job is to migrate it to ASP.NET web-based application. Now boss requires to keep Access as database and develop ASP.NET code against it.
My question is, is there any disadvantages of using Access as database in ASP.NET application? (e.g. optimistic concurrency issue?) Should I persuade boss to upgrade Access to MS-SQL?
Many thanks!
We've used Access as a backend for web sites with good success. It's cheap, can be used effectively by moderately skilled programmers, and you can store the MDB on a document server so it gets backed up.
Most IT people dislike Access, but from a business perspective, Access can be very valuable.
MS Access is notoriously unstable in multiuser environments. A WEB app is by definition heavily multi-user.
So IMHO leaving MS Access as underlying DB is a call for trouble. At least use SQL Express (it is free)
The problem you are going to face in upgrading from Access to MS-SQL is that there is a major cost investment for the application. If your company already has the infrastructure in place(licensing, hardware...) then you won't have such a hard fight to pursuade your boss.
As for a technical answer:
I'd say you need to let you boss know that access databases aren't ideal for concurrent usage which a web application suggests is the intended goal of the application. My view is that Access is for database information that a SMALL set of users will be simply using for small data entry and querying. NEVER use Access to build an enterprise-level solution.
If you are planning to upgrade a Microsoft Access database to SQL Server 2008, use the SQL Server Migration Assistant (SSMA) rather than the upsizing wizard built into MS
10+ tips for upsizing an Access database to SQL ServerAccess.
Your boss probably likes to do ad-hoc stuff with access / excel. If you move the DB to SQL Server Express you can use Access and it's linked table feature to let your boss keep doing his ad-hoc needs through Access while keeping the data in SQL Server Express. If you keep the linked tables named the same as the old physical ones all his reports and queries will should keep working.
I'm an Access promoter, but not for use on websites because Jet/ACE is not threadsafe (though Michael Kaplan once said that is is threadsafe if you access it via ADO/OLEDB; I don't quite understand how a database abstraction layer can wash away a characteristic of the underlying database engine it's calling, but if MichKa said, it's 99% likely to be true).
Now, the exceptions would be if you're using it for prototyping something that will use a different database, or if it's read-only, or is read-write but will only ever have a very small number of users.
Michael Kaplan's website, trigeminal.com, used to use a Jet database as the back end (it may still -- I don't know that MichKa ever changed it), and when that was his main website he reported getting 100K hits a day. But it's a read-only site, so fits my restrictions.
There are so many different alternatives and they are mostly easy to use that I just don't see the point of trying to use Jet/ACE as back end for a website. I'd never do it myself (all the websites I'm responsible for use MySQL).
Simply put, go with MSSQL. Express edition is free, and will give you everything you need to migrate away from Access. These articles are talking about Access applications specifically, but the same issues will plague you.
http://resources.zdnet.co.uk/articles/features/0,1000002000,39285074,00.htm
https://web.archive.org/web/1/http://techrepublic%2ecom%2ecom/5208-6230-0.html?forumID=102&threadID=205509&messageID=2136367
Does anyone know of a web based MS SQL manager (in ASP.NET or classic ASP)? I'm getting sick of using their studio software, and use MySQL a lot too, so I'm used to the web based management. Thanks :)
Check out SQL Web Data Administrator, it's ASP.NET and sounds like it fits the bill. Not sure I'd ever let it exist outside a local network, but if you're running phpMyAdmin or the like then it's probably not much different.
(Also, spend a week using the real MySQL command-line client - you'll learn to love SQL SMS with all it's clicky draggy syntax-colored quirks.)
I do not know of any open source or free solutions for this, and honestly I'm going to doubt that you are going to find anything at that level that is going to do everything you need.
There is a commercial offering myLittleAdmin that works very well, but it is expensive.
I've been working on a Web based SQL Management Studio that works for the most part. Code at GitHub: https://github.com/sanin17/WebSQL or a demo at https://www.saninsoftware.com/WebSQL/Home/Start/
We have a PeopleSoft installation and I am building a separate web application that needs to pull data from the PeopleSoft database. The web application will be on a different server than PeopleSoft, but the same internal network.
What are my options?
This one's an oldie but it may still be of interest.
PeopleSoft has it's own schema within the host database (Oracle, SQL Server, DB2 etc) which are the PSxxx tables, eg: PSRECDEFN is the equivalent of Oracle's DBA_TABLES. These tables should not be touched by any external code. The application tables are stored in PS_xxx tables, eg: PS_JOB. These tables can be read and updated by any SQL code.
Many batch programs in PeopleSoft (eg: Application Engines, COBOL or SQRs) access the tables directly, and this is the fastest way to get data into or out of the database. However PeopleSoft has quite a rich application layer which is bypassed when doing direct SQL. This application layer must be replicated in direct SQL code, especially for inserts or updates. There may be updates to other tables, calculations or increments of database-stored counters.
To determine how to do this one must look through the PeopleCode (a VB6-like interpreted language), page design (via Application Designer) and use the PeopleCode and SQL trace tools. These days the application layer is huge, so this can be a lengthy task for non-trivial pages. PeopleSoft groups related pages into "Components", and all pages in the component are saved at the same time.
Component Interfaces were introduced with PeopleTools 8 as a means to avoid doing all of this. Using a generator within the PeopleSoft app designer, a Component Interface is generated based on the component. For many components these can be used to access the pages as a user would, and can be accessed via PeopleCode programs, and therefore via App Engine programs and via the Integration Broker. They can also be wrapped in Java code and access directly by code able to execute against the app server with a web service wrapper. This method is best for low-volume transactions: heavy extracts work better with native SQL.
The online development and tracing tools in PeopleSoft are pretty good, and the documentation is excellent (although quite extensive) and available on: http://download.oracle.com/docs/cd/E17566_01/epm91pbr0/eng/psbooks/psft_homepage.htm
If you are just looking at bringing out data from a given Component, the easiest way would be to turn on the SQL trace (under the utilities menu in PeopleSoft) and bring up some records for the Component. Wading through the trace file will give you a good idea of what to do, and much of the SQL could be cut and pasted. Another method would be to find an existing report that is similiar to what you are trying to do and cut out the SQL.
Have a PeopleSoft business analyst on hand to help you develop the requirements wouldn't hurt either.
Yes - Integration Broker is Peoplesoft's proprietary implementation of a publish/subscribe mechanism, speaking xml. You could of course just write code that goes against your database using JDBC or OLE/ODBC. Nothing keeps you from doing this. However, you must understand the Peoplesoft database schema, so that you are pulling from, or inserting/updating/deleting all of the proper data. Peoplesoft takes care of this for you.
Also, check out Component Interfaces - and they are exposed as an API to Java or C/C++.
I guess it depends on your requirement, and which version of PeopleSoft you're on.
Do you want real-time lookup? If that's the case then you'll want to look at Web Services/Integration Broker.
If you want a batch/bulk export then a scheduled App Engine would do the trick.
The best way is to use Integration Broker (IB) services to expose the PeopleSoft database data to external applications. The external application will be able to access the PeopleSoft IB services as XML over HTTP, thus allowing you to use any widely used XML parsers for this purpose.
The problem with component interfaces as opposed to Integration Broker is that component interfaces tend to be much slower than direct DB access from within IB service PeopleCode. Also future additions to the component attached to the component interface sometimes tend to 'break' the interface.
For more details on PeopleSoft Integration broker, you can access the online documentation at http://docs.oracle.com/cd/E26239_01/pt851h3/eng/psbooks/tibr/book.htm
Going directly to the database means you have to re-create the presentation logic... see my longer answer above. You can do this for simple pages but otherwise using a component interface is the way to go.
You can also write a sqr process for bulk data extraction. SQR will create the output file which the other application can pick. SQR would be faster than the application engine programs as it performs most of the operations in memory.