In SAP BO 4.1 Client Tool , Do we have any option to edit prompt values .
For Example : I have an ID values from Database in the following format – ABC34526
But I need the ID Values to be displayed in the Prompt List as 34526 alone . I don’t want that to be changed in the database level.
Can anyone please suggest me the solution.
Regards
Riya
You can do that at universe level by using sql functions.
Related
I am using Thingworx Platform for IoT. I have connected Thingworx and SQL. I have created 2 database SQL services of the type query and command. Also I have created two tables named Temperature and Humidity.
I am getting Temperature and Humidity values in Thingworx platform. But I am unable to send it to the database, can anyone help? How can I call the properties in the command service?
Database.Conf sql Command code
insert into INFO(Temperature)
values ([[]]);
Thing-Test Subscription Code
var params={Temp:me.Temp_Prop,Hum:me.Hum_Prop};
var result=Things["DatabaseConf"].InsertRecords(params);
When you create a service in ThingWorx you can select the type: "query" is a valid option when you have to insert or retrieve values from a database. You can test the query on SQl and copy/paste into the service.
Check if the thing that connects you to the DataBase has the property "isConnected" equal to True.
Maybe you should also think about how to trigger the Insert service, you can use ValueChange triggers or a Periodic Trigger.
You need an additionnal service of type javascript where you can retrieve the properties, using me.property and invoke the sql services. You can add input parameters to the sql services and use them like this: [[inputParameter]]. In your example that should look like:
insert into INFO(Temperature)
values ([[temp]],[[Hum]]);
If you use the arrow on the right of your input parameter, ThingWorx will write it for you in the proper way already.
I've successfully connected to a IBM DB2 database in SPSS using the connection wizard. However, I haven't found a working method to do this using SPSS syntax. Has anyone any experience with this?
Normally you'd access it via this Syntax:
GET DATA /TYPE = - insert one of these types - ODBC,OLEDB,XLS,XLSX,XLSM,TXT
Whichever is the type that you wish to access, you can also use SQL within the SPSS syntax editor. This is how I connect to my database from the syntax:
GET DATA
/TYPE=ODBC
/CONNECT='DSN=MAVSQL;Description=SQL;UID=;APP=IBM SPSS Products: Statistics '+
'Common;WSID=MAVNEW;DATABASE=Players;Trusted_Connection=Yes'
/SQL='SELECT Id, Faction, Active, Level, Name, Allignment, CurQuest, '+
'PrevQuest, DeathCount, LastDeath, LastLogon, Created, Class, RacAB, '+ 'Comments, Test, Age, RealName, Email FROM dbo.DSOL'
/ASSUMEDSTRWIDTH=255.
CACHE.
EXECUTE.
DATASET NAME DataSet1 WINDOW=FRONT.
Hope that helps, I know the database I accessed is a SQL database but perhaps you can use the same methodology to access your IBM DB2 database.
Besides pasting the syntax shown in the last panel of the Database Wizard, which includes the connection string and the SQL that goes with the GET DATA command, you can save the query as an spq file from that last panel and use that again in the Database Wizard by choosing Edit Query in the first step.
Does anyone know of the impact on SQL Server of adopting 'two part' user Windows Loginnames in the form "fred.bloggs" instead of "bloggsf"?
I have scoured the Microsoft Knowledgebase and can nothing clear about one or the other: only that all examples shown by them are in the 'single word' format.
I have tried to use fred.bloggs ( that is fred dot bloggs ) in some SQL statements and get error messages, so they obviously cannot be used in a straight forward form.
You need to wrap a login like this in brackets, like: [your.login]
There is no impact on the SQL Server engine and performance.
A user name is a user name, whether there is a . in the middle or not.
The only issue is that of how the name is interpreted - ensure you use [] when specifying a user name, otherwise SQL will interpret the part before the . as a schema name.
So, for CREATE LOGIN, you should do:
CREATE LOGIN [xxxxx.yyyyy]
I have a SQL Script with the following line
declare #input varchar(20)
Select * from Employees where [dept] =
#input
What I want is When I execute the above script in SQL 2005 I want to prompt for an input By opening an inputbox etc., such that the value is accepted in '#input' variable and so the user retrieves the records giving dynamic inputs.
You can't do that. The database doesn't have a user interface, so there are no means of prompting for a value.
You have to make an application that prompts for the value, queries the database and displays the result.
You're really asking for a nonexistent feature but there are a few workarounds:
SSRS allows you to define a "report" with parameters that will take the form of input boxes etc for your users.
If you're ok with the users using SSMS, create the query as a stored procedure and have them use the execute option in the left-hand tree (this prompts for parameter inputs).
Here's what you want
Accepting User Input
But it's for Oracle( ! ) . I hope this will work for other dbs also
Or use C#; Rapid Application Development Using SQL Server 2005 Compact Edition and Visual C#.NET
Access 2007 databases querying linked oracle 10g tables are returning flawed result sets when using the WHERE clause to filter-out unwanted records. Oddly, some filtering is happening, but not reliably.
I can reliably demonstrate/produce the problem like this:
Create a *new* database with Access 2007.
Create a second *new* database with Access 2007, and then "save-as" 2000.
Create a third *new* database with an older version of Access.
Run the following query in each database:
SELECT
STATUS,
ID,
LAST_NAME,
FIRST_NAME
FROM
Oracle10g_table
WHERE
STATUS="A"
In both databases created with Access 2007, running this query will give you a result set in which some of the records where (STATUS="A") = false have been filtered out, but not all of them.
In databases created with older versions of access, the where clause filters properly, and the result set is correct.
STATUS is a text field
The table is a "linked" table to an Oracle10g Database
The table has 68k rows
I've tested my timeout at 60, 1000 and 0
Has anyone run into this problem?
I wonder if this is a new "feature" of access that will also affect 2010. Could this have anything to do with ODBC?
Thanks for any help,
- dave
MORE...
I just tried an alternate form of the query, using HAVING instead of WHERE, and it worked! Problem is, besides that this shouldn't change anything (yes -- more virtual tables, but shouldn't change the end result) my end-users will be using the Access 2007 visual query designer, not typing SQL directly, which is going to default any criteria they enter into a WHERE.
My hunch is that one of your ODBC drivers used by Access to connect to Oracle is treating "A" as a column name not the literal 'A'. Have you tried single quotes on the 'A'? In Oracle double quotes are used to reference column names, is there a column named "A" by any chance?
Oracle Query Example #1
Select object_name from all_objects
where "OBJECT_NAME" = 'DUAL'
Oracle Query Example #2
with example as (
Select object_name as "Fancy Column Name" from all_objects
)
select * from example
where "Fancy Column Name" = 'DUAL'
I've had a similar problem. In my case, changing the ODBC driver worked, but I could also just change the 'unique record identifier' to a column with no nulls in it. It still doesn't have to be the "right" unique record identifier.
This turned-out to be an ODBC-related issue. Our tech support service unit installs connectivity on each of our workstations -- they program it themselves, and who knows what they actually put into it -- but the net result is that when you link to an ODBC datasource with Access (of any version), our network servers show-up in the 'machine data source' tab, so we just click on the one we want and away we go. This has worked well until Access 2007.
What I did was create a "new" machine data source, which let me choose the ODBC driver myself (instead of making me use the one our tech support folks created). I picked "Microsoft ODBC for Oracle", entered the name of the server I wanted, and that all it took. Now the WHERE-clause inconsistent filtering problem is solved (I hope).
The only thing remaining is to send this back to our tech support folks, so they can clean-up their installation. Should I ask for hazard pay? :-) hehe