What are the advantages of oracle forms over adf, and also disadvantages.
Does some companies replaces oracle forms with adf and why?
Regards
First off, Oracle has ceased the Forms as a project some time ago, now it also stopped supporting it.
Forms used to be a framework for desktop applications with easy connection to Oracle database, pretty much like VBS on top of Access.
ADF is a complete framework covering all middleware aspects of an MVC architecture.
Comparing ADF to Forms is something like comparing Ferrari to Yugo.
advantages of oracle forms over adf is oracle forms are much fast as compare to adf form and easy connection to Oracle database not need to lot java code to get stored procedure/dyanmic query just connect and start writing pl/sql.
Related
I have used a variety of WYSIWYG web builders before. I now have a new website that I would like to create that is a bit beyond my skill set. The website will need to have some kind of IDX plugin or interface for real estate listings. There are a ton of different options out there for this. However mine will also - ideally - display microsoft access based forms and reports on specific pages. I'll need to design how the forms & reports are displayed. A plugin would be fine. My understanding is that Access can interface with the web through asp.net as long as the db is hosted in the cloud. I also have a mail chimp account that should be connected with the same site. I would like to know if anyone with more technical knowledge than myself can make any recommendations as to how to pull these pieces together and if I should ask any specific hosting or servicing questions as I do my research. Many thanks!
Well, a c# program (non web) can connect to sql server.
A c# program or a foxPro, or even a vb program can connect to MS-access.
And a web site can connect to sql server, or MS-access.
However, in ALL of these cases, we talking about a program interface that allows one to read the tables as a database.
Access has two parts.
The database part. This part can be consumed by c++, asp.net (web site), FoxPro, V6, vb.net and just about ANY development set of tools that supports the MS-Access ODBC drivers.
However, you can't call MS-Access "just" a database. MS-Access includes two parts:
The database part (this is the database engine). This ONLY allows you to open the database table(s) and work with the data. So VB6, or FoxPro, or vb.net can thus read + use MS-Access as the database.
However, this has ZERO to do with code, queries, forms, and reports written in MS-Access.
So, when someone decides to use SQL server + a web site?
Then you have use of the tables and can submit sql to the database engine. That database engine might be Oracle, or MySQL, or SQL server or MS-Access data engine (ACE/JET). However in all of these cases, you not using VBA code from MS-Access nor are you using reports, nor are you using forms.
So, Access ALSO include a IDE and development part. That development part allows you to build a application. But a application has ZERO much to do with a database.
So, while you can use the data from MS-Access and connect to the tables, the forms, the code, the reports have ZERO to do with web devleopment, and thus the forms and code in that Access database can no more be used on the web then can some code written using Turbo-Pascal, FoxPro, VB6 or any other desktop development system. VB6 has ZERO ZERO to do with web development. Foxpro has ZERO ZERO to do with web development. And Access has ZERO ZERO to do with web development.
So you can "use" the data from FoxPro or say the data from MS-Access in a web site, but ZERO OF THE code in such desktop systems can no more be used for the web.
You can no more take desktop code for windows and run it on a Apple II, a iPad, a Android phone, or run such code in a web site. They are about as different between a bicycle and a helicopter.
So the ONLY part you can use from MS-Access applications written for the desktop part? Answer zero, none, nada!
The only part that you can use from a MS-Access database say in FoxPro? Only the data part - not the code and UI parts.
The only part you can use from a MS-Access database say in VB6? Only the data part - not the code and UI parts.
The only part you can use from a MS-Access database say in VB.NET? Only the data part - not the code and UI parts from MS-Access.
The only part you can use from a MS-Access database say in c++? Only the data part - not the code and UI parts from MS-Access.
The only part you can use from a MS-Access database say in a asp.net web site? Only the data part - not the code and UI parts from MS-Access.
So you are confusing the application part (code, forms, reports) that belongs to a given application. If you going to use a whole new different development system? Then what system in the last 30 years, going all the way back to say software written in Turbo-pascal, c++, VB6, FoxPro or ANY system could you by some magic act use the code and parts from those DIFFERENT application systems in another new application you plan to write?
The answer is ZERO parts!!!
You can no more take code and forms written in say Pascal and expect that code to now run and be used in say VB6, or VB.net.
So, you are most free to move/take/grab/consume the data from MS-Access and use that in a web site. But the code, form, reports etc. written in MS-Access cannot be used for the web, no more then some forms and code you wrote in BASIC for your Apple II can be used on the web.
The only part you can move in a automated fashion from MS-Access applications is the data part - not the code part.
You can no more take BASIC code and forms from a c++ program and shove them into say an MS-Access application you plan to write.
So, you MUST distinguish between the data parts of a given application, and that of the UI and forms and code. In general, since the VERY first personal computer came out, this MOST basic and fundamental concept? Code for one application and system cannot be salvaged, used, nor converted in some automated fashion.
If you want to move code from c++ to MS-Access? You have to re-code and re-write that code.
And if you want to move code from MS-Access to c++? You have to re-code and re-write that code.
And if you want to move code, forms, logic, reports from MS-Access to some other new platform - say like some new set of web development tools? Once again, this a manual process, and it been that way since the very first computer came out!!!
so there are a gazillion web development platforms. More platforms exist then there are flavors of ICE cream. You have to go and find one you like, or one that suits your fancy, or what that maybe you took a few courses. However, not knowing your past experience, and ALSO that outright recommendations of software product X or product Y goes against the code of conduct on StackOverflow. And this is a good thing since then these boards would be swamped and over-run with people selling their wares and products here as opposed to a community that helps developers answer coding and development questions based on a particular tool or platform.
We are planning to migrate an Oracle 10g database to SQL Server 2008 R2. At the moment nothing is implemented in the target database and this will give us the opportunity to change and improve the existing schema during the migration.
Not only the data, but also stored procedures and views have to be imported.
I already worked with SSIS and I found an excellent product for data manipulation. A colleague mentioned SSMA for the migration. However after some research on the net it seems that it would be suitable mainly for data migration and conversion, while SSIS seems to provide a wider set of functinalities (Tasks, custom scripts, etc).
Which are the pro/contra of the two products and which one would best fit for the task?
I would recommend a hybrid approach. Use SSMA to convert the schema and objects from Oracle to SQL Server. Then improve and or change the objects as you see fit on the SQL end. Once your satisfied with your new schema. Use SSIS to move the data still waiting on the Oracle side into the new schema waiting for it on SQL.
As for a quick comparison of SSMA and SSIS... SSIS is by far superior for the ETL aspects of moving data from one place to another; but I wouldn't necessarily recommend it for the creation/modification phase of what you describe above. I think you'll find that process much easier with SSMA. On the flip side SSMA doesn't offer much in the way of transformation during the copy process.
I would go for an hybrid of the two.
Do you know you can trig SSMA from command line? This way you can execute the SSMA migration as a part of the SSIS solution.
You can also save your SSMA project as an SSIS package:
Once migrated keep doing the extra work with SSIS.
Were still using Reporting Services for SQL2008 (not SP2). I recently started using report builder 2.0, but it looks like report builder isn't able to modify data models - and VS2010 lacks business intelligence features. My question is: Have data models been depreciated? If not, what is the current tool for managing them? I have new reports to write so I'm trying to think ahead. Can datasets be used, and access controled, for ad-hoc reporting?
There isn't a way to modify the report models using vs2010 you would still have to have vs2008 BIDS installed to be able to modify these. It looks like reports models may be depreciated from SQL 2012 (http://social.msdn.microsoft.com/Forums/en/sqlreportingservices/thread/0d0650d1-6d40-4d12-a471-54fb29b3356d).
If you starting a new project then personally I would look at using shared data sets based on views or stored procedures as these will be a lot easier to maintain and use. You can then use the permissions on these to control who has access to what.
I recently started a project where I was set to build an ADP based application in Access 2003. The font end GUI was going to be in Access while all the data resided in MS SQL Server. I say "was", because the powers that be have decided that Oracle Forms might be a better choice than Access and SQL Server. The place where I am doing this work is an Oracle shop where they use Oracle 10g. They also use Oracle Forms quite a bit internally.
As for me I am always up for learning anything new. I have always been a rather "eclectic" developer (I work with .NET WinForms, ASP.NET, Java, C#, Python, and Access) so I would not mind moving to Oracle Forms as long as it could do the same things as MS Access (hopefully even more as VBA is rather limited).
So my question is this. How does Oracle Forms (10g) compare to MS Access for developing a GUI application? Access uses VBA for it's language, what does Oracle Forms use? I know the Forms app is a Java applet. Does that means you can write Oracle Forms using Java?
How does Oracle Forms (10g) compare to MS Access for developing a GUI application?
If you're accessing an Oracle database, I'd prefer Forms. Even better, I'd go for Apex. But that's probably partly because I'm used to these environments. I hated trying to build anything more than the simplest UIs in Access.
Access uses VBA for it's language, what does Oracle Forms use?
PL/SQL
I know the Forms app is a Java applet. Does that means you can write Oracle Forms using Java?
You can incorporate Java beans if you need specific custom components, but normally you don't need to. All your business logic you would normally code in SQL or PL/SQL, either in the form or on the database.
If you were going with an Access ADP, why not go with an Access MDB with ODBC? This has been MS's recommended setup even for apps using SQL Server (except for reporting, where ADPs have some advantages) for about the last 5 years or so.
ADPs are on the way out, it seems, not having had any changes/fixes in the last two versions of Access (A2007/A2010). They always seemed to me to be rather half-baked, but then I was comparing them to a mature platform, their sibling MDBs.
We have a large collection of DTS packages that need to be converted to SSIS as part of SQL upgrade?. How effective is this tool compared to the wizard?. Some of the functionality that is available in DTS
Import/Export
SQL operations
Copying/Renaming/moving files
Activex scripts (Not complex, most of the business functionality is in Stored procedures). Any help in sharing documentation or web links or any insight is well appreciated.
You can find a full comparison here: http://www.pragmaticworks.com/products/business-intelligence/dtsxchange/DTSxChange-vs-MSWizard.htm
At a high-level, the existing Microsoft wizard does not handle some common tasks like Dynamic Properties Task. It also doesn't handle things like ODBC or all the flat file conditions. With the DTS xChange tool, it will migrate pretty much all conditions, re-engineer the logging and auditing framework of the package and turn on some of the new features in SSIS. It also includes BI xPress, which will help migrate ActiveX Scripts post-migration with code snippets.