For my C# application I need to access some data from SAP Tables based on use selections. In this context I made use of .net connector + RFC_READ_TABLE to read the data from single table and it works. After further review I found 3 issues with this approach.
RFC_READ_TABLE is not supported RFC from SAP , so most expert agree that it should not use in production
RFC_READ_TABLE does not support table join.
Select * query does not work for most cases as data_buffer_exceed error is thrown
I did some research on ABAP side and I did not find any alternative API / RFC / BAPI that can accept SQL statement as input argument on runtime.
I need something like DataTable in C#.
1) RFC_READ_TABLE is not supported RFC from SAP ==>> This is used by millions of customers and within SAP's own development all over the place. This IS the official API for generic table access. Use it and worry not.
2) RFC_READ_TABLE does not support table join ==>> You can always join in your own application. If you don't want to do it or cannot do it (like performance reasons) then ask your ABAP contact to prepare a RFC-enabled function module for you. That has nothing to do with a thing being a BAPI. BAPI means something completely different. BAPIs can be very difficult, that is correct, but RFC enabled query function is not a BAPI. BAPIs happen to be RFC-enabled quite often, but there is no link between those things.
3) Select * query does not work for most cases as data_buffer_exceed error is thrown ==>> With all due respect you are not supposed to be reading everything anyway, you need to do your research first and request only those fields you really need. Unless this is some sort of a BI generic tool, you don't need all fields. I can tell from the experience.
cheers Otto
To allow .NET client app to send an unchecked SQL statement is a bad idea both security- and performance-wise.
The standard way would be to either create remote enabled function modules or use Gateway to expose data as ODATA.
http://scn.sap.com/community/gateway
Alternative table is DDIF_FIELDINFO_GET FM. Please use this for details
As of now there is no join in RFC_READ_TABLE. However the steps that you could incorporate (which is a lengthy one) is:
Create a batch file to pass your input SAP tables as parameters to your code.
Extract relevant data by putting filters (which is possible) in RFC_READ_TABLE or RFC_GET_TABLE_ENTRIES to get the structure & data separately; since RFC_READ_TABLE has 512 byte limitation - which can be bypassed by using RFC_GET_TABLE_ENTRIES FM.
Note: But data in the 2nd FM is in one string, which you need to filter based
on the structure that you have extracted.
Now you should have 2 outputs of both the tables.
Upload them to MS Access via a simple batch job, which should be fully
automated.
Once uploaded to MS Access, please write your join to connect both.
Check out my video - where I have bypassed the 512 byte.
I have 2 more videos up in youtube.
Hope this helps.
Thanks
Ram.S
Related
Im designing a UWP app that uses an SQLite database to store its information. From previous research I have blearnt that using the SQLite function SQLiteConnection.Update() and SQLiteConnetion.Insert() functions are safe to use as the inputs are sanitised before entering in the database.
The next step I need to do is sync that data with an online database - in this case SQL Server - using a service layer as my go between. Given that the data was previously sanitised by the SQLite database insert, do I still need to parameterise the object values using the service layer before they are passed to my SQL Server database?
The simple assumption says yes because, despite them being sanitised by the SQLite input, they are technically still raw strings that could have an effect on the main database if not parameterised when sending them there.
Should I just simply employ the idea of "If in doubt, parameterise" ?
I would say that you should always use SQL parameters. There are a few reasons why you should do so:
Security.
Performance. If you use parameters the reuse of execution plans could increase. For details see this article.
Reliability. It is always easier to make a mistake if you build SQL commands by concatenating strings.
My requirement is to display source code of RFC. I have a non SAP environment. I believe SAP stores RFC source in one of the tables. If i know the table and column, I can fetch this info. Can anybody share info on this?
Thanks
If i know the table and column, i can fetch this info.
The table is REPOSRC, the column is DATA - good luck.
(For those reading along, the source is stored in a compressed form that is not suitable for external access.)
If you're not commited to your brute-force approach, you could use the function module RPY_FUNCTIONMODULE_READ_NEW - this will return the source as well. Be aware that the source will be of limited use because it will most likely use tons of other stuff from other programs and includes.
Here is what I have:
1) a simple sql file given to me that creates tables and fills them with data
2) a simple sql file that contains PL/SQL procedures I've written for displaying/manipulating the tables
The goal is to create some sort of user interface that allows a student to login, view their transcript, withdraw from classes, etc.
I am using sqlplus. I have procedures that do all the required displaying/manipulating. I am successful at creating a simple command line UI with sqlplus, but the problem arrives when I need to get user input inside a loop (for allowing them to see course information for any number of courses until they wish to go back to the main menu). After doing research, I learned that this would be the job of something like PHP, C, etc. Unfortunately, I am not proficient in any language required, and setting up extensions and such have proven to be extremely complicated.
I am capable of learning the necessary techniques to complete this, but I do not know which direction to go in. What is easiest to implement a simple UI? Should I use PHP? C? C++? Is there some sort of program out there that automatically creates simple UIs given database data?
Oracle Apex is perfect for your situation. You can easily create web based forms and reports to perform all CRUD operations. Plus, it's free to use with any licensed Oracle database: Oracle Application Express
I often find myself writing one off queries to either answer someone's question or trouble shoot something and I would like to be able to quickly expose the on demand refreshable results of the query graphically so that I can share these results to others without having to go through the process of creating an SSRS report and publishing it to a reporting services server.
I have thought about using excel to do this or maybe running a local SSRS server but both of these options are still labor intensive and I cannot justify the time it would take to do these since no one has officially requested that I turn this data into a report.
The way I see it the business I work for has invested money in me creating these queries that often return potentially useful data that other people in the organization might want but since it isn't exposed in any way and I don't know that this data is something they want and they may not even realize they want this data, the potential value of the query is not realized. I want to increase the company's return on investment on all these one off queries that I and other developers write by exposing their results graphically so that they can be browsed by others and then potentially turned into more formalized SSRS reports if they provide enough value to justify the development of the report.
What is the fastest way for me to take a query and turn it into a refreshable graph of the results set?
Why dont you simply use what you may already have. Excel...you can import data via an ODBC / Oracle / SQL Connection. Get Data..and bam you can run the query and format it right in the spreadsheet and provide sorting etc. All you need to supply is the database name and user name and password to connect to the db.
JonH is right regarding Excel's built in ODBC support, but I have had tons of trouble with this. In my case, the ODBC connection required the client software to be installed so that it could use the encryption methods, etc. Also, even if that were not the case, the user (I believe) would still have to manually install and set up an ODBC connection.
Now if you just want something on your machine to do the queries and refresh them, JohH's solution is great and my caveats are probably irrelavent. But if you want other users to have access, you should consider having a middle-man app (basically a PHP script, assuming a web server is an option for you), that does a query, transforms the results into XML, and outputs it as "report-xyz.xml". You can then point anybody running a newer version of Excel to that address and they can very easily import the data into Excel with no overhead. (basically a kind of web service).
Keep in mind, I don't think you should have a web script that will allow users to make queries to your Database server! You would have some admin page where you make pass the query in and a new xml file with the results gets made. So my idea is also based on the idea that you want to run the same queries over and over without any specifics passed in. (if that were the case, I'd look into just finding a pre-built web services bridge for your database that already has security features built in. Then you could have users make the limited changes allowed.)
I have large and complex SQL Server 2005 DB used by multiple applications. I want to create a data-dictionary for maintaining not only my DB objects but also cross-reference them against applications that use a specific object.
For example, if a stored procedure is used by 15 diffrent applications I want to record that additional data too.
What are the key elements to be kept in mind so that I get a efficient and scalable Data Dictionary?
So, I recently helped to build a data dictionary for a very large product. We were dealing with documenting more than one-thousand tables using a change request process. I can send you a scrubbed version of the spreadsheet we used if you want. Basically, we captured the following:
Column Name
Data Type
Length
Scale (for decimals)
Whether the column is custom for the application(s) or a default column
Which application(s)/component(s) the column is used in
Release the column was introduced in
Business definition
We also captured information about who requested the addition, their contact information, etc. Our primary focus was on business definition, and clearly identifying why a column was being used or created.
We didn't have stored procedures in our solution, but bear in mind that these would be pretty easy to add to the system.
We used Access for our front-end, even though SQL Server was on the back end. It made it pretty easy for us to build out a rich user interface without much work, using the schema we had already built out.
Hope this helps you get started--feel free to ask if you have additional questions.
I've always been a fan of using the 'extended properties' within SQL Server for storing this kind of meta data. In this way the description of each object lives alongside the object and is accessible by anyone with access to the database itself. I'm sure there are also tools out there that can read these extended properties and turn them into a nicely formatted document.
As far as being "scalable", I don't know of any issues related to adding large amounts of data as extended properties; or I should say I've never had any issues with this.
You can set these extended properties using SQL Server Management Studio 'property' dialog for each table/proc/function/etc and can also use the 'sp_addextendedproperty'.