I'm trying to create custom doctrine type that simply increments an integer by one. I want to do it on a database level, with simple x=x+1 where x is the column name.
But I cannot find how to reference the column name and how to force (if necessary) to save it unquoted.
Is there any way to do this with custom type?
Related
I have several fields that contain exactly the same sql query! Is it possible to place the sql question centrally in APEX in the same way as list of values or as a function in oracle? I am using APEX 18.2
Here are two extended solutions
Pipelined SQL
https://smart4solutions.nl/blog/on-apex-lovs-and-how-to-define-their-queries/
Dynamic SQL
http://stevenfeuersteinonplsql.blogspot.com/2017/01/learn-to-hate-repetition-lesson-from.html
Call me dense, but I don't think I understand why you'd have multiple fields (presumably on the same form) whose source is the same SQL query.
Are you passing a parameter to the SQL to get a different value for each field?
If you are passing a parameter to the SQL query, why not create a database view to hold the query, then pass the parameter to the view. That way, if you need to change it, it's in one place.
If they really are all the same value from the same query, how about using the SQL for one field/page_item, then make the source for the others be the first page item?
I would create a hidden item with the query in the source as text and use &HIDDEN_ITEM_NAME. to reference its value in the source of any item I was trying to display the query.
Finally isolved it with a function and use the type PL/SQL Function Body returning SQL Query in APEX, then i have all in one place. I created a function in SQL developer that returns a SQL query.
Using AWS Cloudsearch, I need to query 2 separate fields for the same value using a structured (compound) query e.g.
(and (or name:'john smith') (or curr_addr:'123 someplace' other_addr:'123 someplace'))
This query works, but I'm wondering if it's necessary to repeat the value for each field that I want to search against. Is there some way to specify the value only once e.g. curr_addr+other_addr:'123 someplace'
That is the correct way to structure your compound query. From the AWS documentation, you'll see that they structure their example query the same way:
(and title:'star' (or actors:'Harrison Ford' actors:'William Shatner')(not actors:'Zachary Quinto'))
From Constructing Compound Queries
You may be able to get around this by listing the more repetitive fields in the query options (q.options), and then specify the field for the rest of the fields. The fields list is sort of a fallback for when you don't specify which field you are searching in a compound query. So if you list the address fields there, and then only specify the name field in your query, you may get close to the behavior you're looking for.
Query options
q.options={fields: ['curr_addr','other_addr']}
Query
(and (or name:'john smith') (or '123 someplace'))
But this approach would only work for one set of repetitive fields, so it's not a silver bullet by any means.
From Search API Reference (see q.options => fields)
I just refactored into a power query function some code that process tables that has an specific structure.
Now, I need to pass another PowerQuery query (that returns a table with a compatible structure) to this function, but the parameter manager only allows to use strings, therefore I need to obtain access to the referenced table using an string with its name.
Any hints?
I have to maintain an App with a SQL Server 2012 back end.
There's a database table containing a bunch of
machine parameter settings, one per column.
Each parameter is an nchar(15) type referencing
a type-dependant lookup-table, e.g.
CREATE TABLE L_MachineSettings (
ID uniqueidentifier NOT NULL PRIMARY KEY,
ParentID uniqueidentifier,
IsActive nchar(15) FOREIGN KEY REFERENCES L_YesNo(Constant),
OnTime nchar(15) FOREIGN KEY REFERENCES L_Time(Constant),
Motor1_InitMode nchar(15) FOREIGN KEY REFERENCES L_InitModes(Constant),
...
and so on (nearly 60 parameters are following, some are ref. the same lookup-tables)
...
)
Each lookup table is built like in this example:
CREATE TABLE L_Lookup_YesNo (
Constant nchar(15) PRIMARY KEY,
TargetValue nvarchar(max),
NotSupportedBy nvarchar(max)
)
INSERT INTO L_Lookup_YesNo
(Constant, TargetValue)
VALUES
(N'No', N'0'),
(N'Yes', N'1')
There are several different machine types among whom, some are not capable
of accepting all values of all lookup tables due to their limited hardware specs.
For those, the field NotSupportedBy in the lookup tables is filled with the machine types not
supporting a value, separated by semicolons, e.g.
INSERT INTO L_Lookup_InitModes
(Constant, TargetValue, NotSupportedBy)
VALUES
(N'Standard', N'144A', NULL),
(N'Extended, N'144B', NULL),
(N'ExtendedPlus' N'144Z', N'AU1220;AU1221'),
(N'ExtendedPlusB' N'144D', N'AU1220;AU1221;AU1401')
The machine types itself are defined in a separate table:
CREATE TABLE L_MTypes (
Name nchar(6) PRIMARY KEY,
Comment nvarchar(max)
)
INSERT INTO L_MTypes
(Name, Comment)
VALUES
(N'AU1220', N'Basic Edition'),
...
A L_MachineSettings row is allowed to be only partially implemented
so it can contain NULL values, as long as it's ParentID
property has been set to another row ID containing the missing
parameters.
Also child row values will overwrite those of the parent's row,
so a hierarchic parameter structure can be build by creating a base setting
and adding only differing values for a new setting while referencing
all other values. If a base value is to be changed, the change "falls through" to
it's childs automatically, so XML files, which represent the final format
of the data, shipped to customers are always containing all recent changes.
I'm now challenged with the job of making those column-lookup-values
machine specific, too, while not throwing the existing database layout
on the heap.
So what I need is a way to store more than one lookup value into a settings field,
which would be associated with a machine type. If no specific value for a specific machine
type is available, the general value should be used on export. The machine-specific values
should be taken from the lookup tables, too.
An important thing is: Next to a GUI (written in C++Builder) some users are also
accessing the SQL Server DB via MS Access and those users are not qualified personnel in terms of databases (you know
what I mean), so there should be only minor changes to the existing structure.
My ideas so far:
Adding a new column MType to L_MachineSettings to add machine specific options to the ParentID setting
Adding machine specific values via semicolon-separation to a field, e.g. "Yes;AU1220:No"
While the first idea seems simple at first, I fear the collisions with the ParentID stuff and the probably resulting chaos.
The second approach will give up the existing lookup relationships, (only breaking that with the lookup-tables NotSupportedBy column until now), so I won't accept that change.
Who has some best practices for me, here?
What built-in routine can I make use of to cast data of type LVARCHAR to data of type TEXT?
The larger context: I have a table with a column that has been defined as LVARCHAR(4096). Now a developer wishes to change the data type of this column to TEXT. Ideally this would be done with:
ALTER TABLE foo MODIFY bar TEXT;
...but in such a case the following error is puked to the screen:
ALTER TABLE can not modify column (bar) type. Need a cast from the current type to the new type.
I have read up on the CREATE CAST construction, but I cannot begin to think what on earth the proper conversion function would look like. Without a function, Informix will not allow the CREATE CAST to work. That is, if I do, simply:
CREATE CAST (LVARCHAR AS TEXT)
...Informix tells me that a cast function is required (which makes sense).
Beware, Informix developers: if you inadvertently run into a problem like this, there is no way to get out of it using SQL or DDL alone. Let me repeat that.
If you have a VARCHAR or an LVARCHAR column that you need to migrate to be a TEXT column, and if you cannot afford to lose data in that column, there is no way to do this in SQL or DDL.
Instead, you must write a program that does the conversion for you inside the database driver, in memory. In my case, I used JDBC mutable result sets and copied the column to a new column, letting the JDBC driver perform the conversion, then dropped the old column, and renamed the new column back to the old column. This general pattern is the only way to migrate existing character data into a TEXT column.
#Storm: Which version of IDS/ODBC are you using? AFAIK, IDS 9 or 10 can't do that without using specific embedded C in server (See boulder site), but in no way you can do that directly through SQL. Blob related functions or so.
Othe way is by using UNLOAD / LOAD.
In my scenario, we have lots of problems: no admin rights to enterprise server, as we are service providers, we only can use database, but cannot modify structure. We cannot modify TEXT fields only by launching queries.