Trigger delay too long

I'm trying to make a 10ms trigger delay using a PCI-MIO-16E-4. However everytime I use it there seems to be a variable delay of about 50ms before my signal is outputted. Is there anyway to remove this extra delay?
Thanks

Although you are getting a longer delay than you are
wanting, this can be caused by a few things. One large factor in delay times
being slightly off are that, unless you are using a real-time system, your PC
is non-deterministic and will not guarantee your delay being exact and
occurring at the exact same time each iteration.
Another factor, partially building on the one above, is the
code you are running and how long it takes to execute. If you have a 10 ms ‘wiat ms.vi’, but your code takes
20ms, then the delay will be ignored because your code ran longer than the wait
timer. This
KB explains more about the wait functions.
David L.
Systems Engineering
National Instruments

Similar Messages

Create trigger waits too long

Hi,
I am creating some triggers on a table, but it is taking too much time, I just query the dba_blockers but no rows appears.
Trigger lock the table?, where I can see why is taking too much time.
Thanks.

Is a trigger:
SET VERIFY OFF;
SPOOL TRG_UI_LOG_FARV_PRECIOS.log;
CREATE OR REPLACE TRIGGER TRG_UI_FARV_PRICE
BEFORE INSERT OR UPDATE
ON MAESTROSCTL.FARV_PRICE
REFERENCING OLD AS OLD NEW AS NEW
FOR EACH ROW
BEGIN
DECLARE
    l_rec ECVENTA.LGTR_LOG_CHANGES%rowtype;
BEGIN
    +=====================================================================+
    | FILENAME                                                            |
    |    TRG_UI_LOG_FARV_PRICE.trg                                       |
    |                                                                     |
    | DESCRIPTION                                                         |
    |    Script Trigger change log
    |    Tabla : FARV_PRICE           in schema MAESTROSCTL            |

Recording start delay - Too long to initiate recording i

Can anyone tell me why when I initiate record it is taking like 30 seconds or longer for the playhead to start moving and recording? I see the swirl processing forever the finally it will catch and start recording my audio. Very frustrating , what do I have set wrong ? I have adjusted the buffers and turned all the plug ins off.

Mark Heupel wrote:
Can anyone tell me why when I initiate record it is taking like 30 seconds or longer for the playhead to start moving and recording? I see the swirl processing forever the finally it will catch and start recording my audio. Very frustrating , what do I have set wrong ? I have adjusted the buffers and turned all the plug ins off.
I think the most common cause for this was using an external drive formatted FAT32. If you are using an external drive for recording audio, use Mac OS Extended with Journaling OFF.
pancenter-

Fms4.5 http broadcast delay is too long

HTTP broadcast delay is too long, I do a test in the LAN, send video using FME 3.2 the flow FMS4.5 server, use the sample folder under the videoplayer to play live video streams, using HTTP delay of 10 seconds or more,(RMTP play live rarely delay), who can tell me, how can I do this problem can solve the delay!

It depend on two things: streams buffering and network speed

How to handle the SQL Error: ORA-01704: string literal too long

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy for Java (vers. 26 Sep 2004), see www.w3.org">
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta content="MSHTML 6.00.2900.2963" name="GENERATOR">
</head>
<body class="BodyContent">
HI please chek the query getting error like string literal too long update PRVDR_ENRLMNT_AGREEMENT B set b.terms=q'#
<div class="widget-title">
<h5>Medical Assistance Provider Enrollment & Trading Partner Agreement - Conditions:</h5>
<a href="# class="btn-minimize pull-right"></a></div>
<div class="widget-content">
<table width="100%" border="0">
<tbody>
<tr valign="center">
<td class="Label" align="left" width="14%" colspan="2" height="32">In applying for enrollment as a provider or trading partner in the Medical Assistance Program (and programs for which the Michigan Department of Community Health (MDCH) is the fiscal intermediary), I represent and certify as follows:</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">1.</td>
<td class="LabelValue" valign="top" align="left" height="32">The applicant, and the employer (if applicable), certify that the undersigned has/have the authority to execute this Agreement.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">2.</td>
<td class="LabelValue" valign="top" align="left" height="32">Enrollment in the Medical Assistance Program does not guarantee participation in MDCH managed care programs nor does it replace or negate the contract process between a managed care entity and its providers or subcontractors.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">3.</td>
<td class="LabelValue" valign="top" align="left" height="32">All information furnished on this Medical Assistance Provider Enrollment & Trading Partner Agreement form is true and complete.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">4.</td>
<td class="LabelValue" valign="top" align="left" height="32">The providers and fiscal agents of ownership and control information agree to provide proper disclosure of provider's owners and other persons criminal related to Medicare, Medicaid or Title XX involvement. [42 CFR 455.100]</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">5.</td>
<td class="LabelValue" align="left" height="32">The applicant and the employer agree to provide proper disclosure of any criminal convictions related to Medicare (Title XVIII), Medicaid (Title XIX), and other State Health Care Programs (Title V, Title XX, and Title XXI) involvement. [42 CFR 455.106 and 42 U.S.C. ? 1320a-7]</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">6.</td>
<td class="LabelValue" align="left" height="32">I agree to read the Medicaid Provider Manual from the Michigan Department of Community Health (MDCH). I also agree to comply with 1) the terms and conditions of participation noted in the manual, and 2) MDCH's policies and procedures for the Medical Assistance Program contained in the manual, provider bulletins and other program notifications.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">7.</td>
<td class="LabelValue" align="left" height="32">I agree to comply with the provisions of 42 CFR 455.104, 42 CFR 455.105, 42 CFR 431.107 and Act No. 280 of the Public Acts of 1939, as amended, which state the conditions and requirements under which participation in the Medical Assistance Program is allowed.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">8.</td>
<td class="LabelValue" align="left" height="32">I agree to comply with the requirements of Section 6032 of the Deficit Reduction Act of 2005, codified at section 1902 (a)(68) of the Social Security Act which relates to the conditions and requirements of "Employee Education About False Claims Recovery."</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">9.</td>
<td class="LabelValue" align="left" height="32">I agree that, upon request and at a reasonable time and place, I will allow authorized state or federal government agents to inspect, copy, and/or take any records I maintain pertaining to the delivery of goods and services to, or on behalf of, a Medical Assistance Program beneficiary. These records also include any service contract(s) I have with any billing agent/service or service bureau, billing consultant, or other healthcare provider.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">10.</td>
<td class="LabelValue" align="left" height="32">I agree to include a clause in any contract I enter into which allows authorized state or federal government agents access to the subcontractor's accounting records and other documents needed to verify the nature and extent of costs and services furnished under the contract.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">11.</td>
<td class="LabelValue" align="left" height="32">I understand that the incentive payment requested using my National Provider Identifier (NPI) number will be made directly to the Tax ID Number (TIN) that was indicated during the registration process.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">12.</td>
<td class="LabelValue" align="left" height="32">I am not currently suspended, terminated, or excluded from the Medical Assistance Program by any state or by the U.S. Department of Health and Human Services.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">13.</td>
<td class="LabelValue" align="left" height="32">I agree to comply with all policies and procedures of the Medical Assistance Program. I also agree that all disputes, including overpayments, may be adjudicated in administrative proceedings convened under Act No. 280 of the Public Acts of 1939, as amended, or in a court of competent jurisdiction. I further agree to reimburse the Medical Assistance Program for all overpayments, and I acknowledge that the Medicaid Audit System, which uses random sampling, is a reliable and acceptable method for determining such overpayments.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">14.</td>
<td class="LabelValue" align="left" height="32">I agree to comply with the privacy and confidentiality provisions of any applicable laws governing the use and disclosure of protected health information, including the privacy regulations adopted by the U.S. Department of Health and Human Services under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and Public Acts 104-191 (45 CFR Parts 160 and 164, Subparts A and E). I also agree to comply with the HIPAA security regulations, as applicable, for electronic protected health information by the compliance date, which is currently April 21, 2005 (45 CFR Parts 160 and 164, Subparts A and C).</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">15.</td>
<td class="LabelValue" align="left" height="32">This Agreement shall be governed by the laws of the State of Michigan and applicable federal law including, but not limited to, the Health Insurance Portability and Accountability Act of 1996 (HIPAA).</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">16.</td>
<td class="LabelValue" align="left" height="32">The provisions of this Agreement are severable. If any provision is held or declared to be illegal, invalid or unenforceable, the remainder of the Agreement will continue in full force and effect as though the illegal, invalid or unenforceable provision had not been contained in this Agreement.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">17.</td>
<td class="LabelValue" align="left" height="32">Failure or delay on the part of either party to exercise any right, power, privilege, or remedy in this Agreement will not constitute a waiver. No provision of this Agreement may be waived by either party except in writing and signed by an authorized representative of the party requesting the waiver.</td>
</tr>
<tr valign="center">
<td class="Label" align="left" width="14%" colspan="2" height="32"></td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">18.</td>
<td class="LabelValue" align="left" height="32">If the nursing facility named on the Medical Assistance Provider Enrollment & Trading Partner Agreement is sold, the seller will notify MDCH of the sale at least ninety (90) days prior to the expected sale date. Further, it is understood that the sale will not be recognized for reimbursement purposes under the Medical Assistance Program until ninety (90) days after such notification. Provisions of 42 CFR 413.135(f) will be retrospectively satisfied at that time. Any exception must be approved in writing by MDCH. The new owner/provider must receive Medicare certification for all Medicaid-only beds in the facility within one year from the date of purchase of an operating nursing facility or from the date of reopening a previously closed nursing facility.</td>
</tr>
<tr valign="center">
<td class="Label" align="middle" width="14%" colspan="2" height="32">Medical Assistance Provider - Employer/Employee Conditions</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">19.</td>
<td class="LabelValue" align="left" height="32">The applicant is employed by the business listed, now referred to as the "employer", to provide Medical Assistance Program services to eligible beneficiaries at the service address listed.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">20.</td>
<td class="LabelValue" valign="top" align="left" height="32">The employer and the applicant shall advise MDCH within thirty (30) days after any change(s) in the employment relationship.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">21.</td>
<td class="LabelValue" align="left" height="32">The employer and the applicant agree to be jointly and severally liable for any overpayments billed and paid under Act No. 280 of the Public Acts of 1939, as amended, for services provided by the applicant to eligible beneficiaries.</td>
</tr>
<tr valign="center">
<td class="Label" align="middle" width="14%" colspan="2" height="32">Trading Partner Provisions</td>
</tr>
<tr valign="center">
<td class="Label" align="left" width="14%" colspan="2" height="32">The MDCH and its Trading Partner desire to facilitate the exchange of healthcare transactions ("Transactions") by electronically transmitting and receiving data in agreed formats in substitution for conventional paper-based documents.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">1.</td>
<td class="LabelValue" align="left" height="32">Companion Documents; Standards; Other Documentation. MDCH makes available certain inbound and outbound Electronic Data Interchange (EDI) transaction sets/formats and associated version. From time to time during the term of this Agreement, MDCH may modify supported transaction sets/formats. In submitting Transactions to MDCH, the Trading Partner agrees to conform to MDCH-issued provider publications and MDCH Companion Guides as amended from time to time. The MDCH Companion Guides, incorporated by reference herein, contain specific instructions for conducting each Transaction and as such supplement Implementation Guides issued under the Standards for Electronic Transactions mandated by the Health Insurance Portability and Accountability Act of 1996 (HIPAA) as amended. The MDCH Companion Guides are not intended to be complete billing instructions and do not alter or replace applicable physician guides or other healthcare provider billing publications issued by MDCH or by other third party payers. The Trading Partner agrees to comply with the requirements set forth in the applicable MDCH Companion Guides. The Trading Partner, or its vendor, or other authorized technical representative responsible for EDI software will document Trading Partner Information, data formats and related versions, trading partner identifiers, and other information MDCH requires to receive and transmit specific Transactions supported by MDCH.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">2.</td>
<td class="LabelValue" align="left" height="32">Support. 
As to software, equipment, and services associated with each party's performance under this Agreement, the parties agree to provide support services sufficient for Transactions to be exchanged. Each party will assist the other in establishing and/or maintaining support procedures, and will complete appropriate problem determination procedures prior to contacting the other with a support related matter. The parties agree to use all commercially reasonable efforts to avoid and resolve performance and unavailability issues. Each party will perform remedial action, as requested by the other, to assist in problem resolution. Each party, at its own expense, shall provide and maintain the equipment, software, services, and testing necessary to effectively and reliably transmit and receive transactions.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">3.</td>
<td class="LabelValue" align="left" height="32">Data Retention. 
MDCH will log all Transactions for the purpose of problem investigation, resolution, and servicing. The Trading Partner is responsible for maintaining and retaining its own records of data submitted to MDCH. Trading Partners who are healthcare providers will ensure that electronic healthcare claims submitted to MDCH can be readily associated and identified with the correct patient medical and business office records, and that these records are maintained in a manner that permits review, and for the time period as may be required by MDCH or other third party payer responsible for claim payment.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">4.</td>
<td class="LabelValue" align="left" height="32">Proper Receipt and Verification for Transactions. 
Upon proper receipt of any ANSI ASC X12N Standard Transaction, the receiving party shall promptly and properly transmit a functional acknowledgement in return, unless otherwise specified. The functional and interchange acknowledgements must be accepted and reviewed, when applicable, to confirm the receipt of a Transaction. The ability to send or receive functional acknowledgements is applicable only to ANSI ASC X12N Standard Transactions. Additionally, MDCH originated outbound Transactions must be accepted and reviewed, when appropriate, to obtain MDCH's response to specific inbound Transactions. The acknowledging party does not attest to the accuracy of the data contained in the transmission; rather, it only confirms receipt of the transmission.</td>
</tr>
<tr valign="center">
<td class="Label" valign="top" nowrap align="right" width="1%" height="32">5.</td>
<td class="LabelValue" align="left" height="32">Liability. 
MDCH shall not be responsible to the Trading Partner nor anyone else for any damages caused by loss, delay, rejection, or any misadventure affecting such electronic information. In addition, MDCH shall be excused from performing any EDI servi

You cannot use string literal of more than 4000 characters in an Oracle SQL statement. I'm not going to count that string you so rudely posted but I presume it is longer than that figure. You'll need to use a variable instead.
declare
 c clob := '<your vast XML doc here>';
begin
 update PRVDR_ENRLMNT_AGREEMENT B set b.terms= c
 where ....
{code}
Cheers, APC

Taking too long time to login!

Hi Experts,
I am facing a low performance problem in B1. After I enter the user id and password on the login screen of B1 in our client PCs, it takes a long time (around 180sec) to log in to the system. The initial log in time is too long for end users.
However, once it is logged in it running fine. Also, it is fast if I try to login in the server machine (localhost). I have checked the network and the hardware. Everything is fast and smooth except login.
Is there any way out to make the login process faster?
Please advise
Ken Ma

Dear Ken,
Sometimes the login process can be delayed due to several factors, please verify your clients machines meet the minimum requirements. You can use the below link to get the necessary documents:-
http://channel.sap.com/sbo/documentation
I would suggest to have at least 1Gb Ram on your clients machines for better performance.
regards,
Feroz Dosani

OPM process execution process parameters takes too long time to complete

PROCESS_PARAMETERS are inserted every 15 min. using gme_api_pub packages. some times it takes too long time to complete the batch ,ie completion of request. it takes about 5-6 hrs long time ,in other time s it takes only 15-20 mins.This happens at regular interval...if anybody can guide me I will be thankful to him/her..
thanks in advance.
regds,
Shailesh

Generally the slowest part of the process is in the extraction itself...
Check in your source system and see how long the processes are taking, if there are delays, locks or dumps in the database... If your source is R/3 or ECC transactions like SM37, SM21, ST22 can help monitor this activity...
Consider running less processes in parallel if you have too many and see some delays in jobs... Also indexing some of the tables in the source system to expedite the extraction, make sure there are no heavy processes or interfaces running in the source system at the same time you're trying to load... Check with your Basis guys for activity peaks and plan accordingly...
In BW also check in your SM21 for database errors or delays...
Just some ideas...

Execution time of a simple vi too long

I'm working with LabVIEW 6.0.2 on a computer (AMD ~700MHz) under Windows 2000. The computer is connected to the instruments (eg Keithley 2400 Sourcemeter) via GPIB (NI PCI-GPIB Card). When trying to read the output of the K2400 with a very simple vi (sending the string READ? to the instrument with GPIBWrite (mode 2) and subsequently reading 100byte with GPIBRead (mode 2) from the instrument, the execution time mostly exceeds 1s (execution highlighting disabled). Sometimes, it can be much faster but this is very irreproducible. I played around with the GIPBRead and Write modes and with the number of bytes to be read from the device as well as with the hardware settings of the Keithley 2400 but nothing seemed to work. The API calls ca
ptured by NI Spy mainly (lines 8 - 160) consist of ThreadIberr() and ibwait(UD0, 0x0000).
As this problem is the main factor limiting our measurement speed, I would be grateful for any help.
Thanks a lot
Bettina Welter

Hello,
Thanks for contacting National Instruments. It seems like the 1 second delay that is occurring is due to the operation being called. ThreadIberr returns the value of iberr, while ibwait simply implements a wait. These two get called repeatedly while the GPIB device waits for the instrument (K2400, in your case) to finish its operation and respond back. It is quite possible that when you query the Keithley to send back 100 bytes of data, it has to gather them from its buffer (if its already been generated). And if there aren't 100 bytes of data in the buffer, the Keithley will keep the NRFD line asserted while it gathers 100 btyes of data. After the data has been gathered, the NRFD line is deasserted, at which point, ThreadIberr will detect the change in th
e ibsta status bit and read the 100 bytes.
So make sure that the 100 bytes of data that you are requesting don't take too long to be gathered, since this is where the main delay lies. Hope this information helps. Please let us know if you have further questions.
A Saha
Applications Engineering
National Instruments
Anu Saha
Academic Product Marketing Engineer
National Instruments

Automatic trim of too long strings

Hi,
if I try to insert a too long string value into a VARCHAR column, I get the error ORA-12899.
Is it possible to set the Oracle database so that too long strings get trimmed automatically?
Thank you.

Hi,
Welcome to the forum!
Unfortunately, there's nothing quite like what you want in Oracle.
Even if you write a trigger to cut off the excess, you can still get the ORA-12899 error. For example, if table_x.col_1 is defined as VARCHAR2 (10), this statement:
INSERT INTO table_x (col_1) VALUES ('ABCDEFGHIJKLMNOP');will get the error, even if you have a trigger that says
:NEW.col_1 := SUBSTR (:NEW.col_1, 1, 10);You could define col_1 as VARCHAR2 (4000), and have a trigger that includes the statement show above, to make sure that the actual values will be 10 characters or less. You cound even have a CHECK constraint (LENGH (col_1) <= 10).
Think carefully about what Someoneelse said. Do you really want to throw away part of what users enter, automatically and without any warning? Will that cause confusion?

String beginning ":OLD.DIAL_..." is too long. maximum size is 239 character

@C:\Y\trigger.sql DIM_DIAL_DIGIT ctva_ra TRG_DIM_DIAL_DIGIT1
:OLD.DIAL_DIGIT_KEY,:OLD.BU_KEY,:OLD.NOP_ID_KEY,:OLD.SDCA_LOCATION_CODE,:OLD.TARGET_REGION_DESC,:OLD.TARGET_COUNTRY_CODE,:OLD.TARGET_COUNTRY_DESC,:OLD.LDCA_NAME,:OLD.SDCA_NAME,:OLD.LDCC_X_COORD,:OLD.LDCC_Y_COORD,:OLD.SDCC_X_COORD,:OLD.SDCC_Y_COORD,:OLD.POPULATION_DATE_TIME,:OLD.ISO_COUNTRY_CODE,:OLD.HOTLIST_IND,:OLD.BLACKLIST_IND,:OLD.UPDATE_DATE_TIME,:OLD.EVENT_TYPE_KEY,:OLD.PROVIDER_DESCRIPTION,:OLD.DM_IND,:OLD.DIAL_DIGIT_OPERATOR_TYPE,:OLD.CALL_DIRECTION_KEY,:OLD.DIAL_DIGIT_DESCRIPTION,:OLD.FORCE_RI_IND,:OLD.TEST_CALL_IND DIAL_DIGIT_KEY,BU_KEY,NOP_ID_KEY,SDCA_LOCATION_CODE,TARGET_REGION_DESC,TARGET_COUNTRY_CODE,TARGET_COUNTRY_DESC,LDCA_NAME,SDCA_NAME,LDCC_X_COORD,LDCC_Y_COORD,SDCC_X_COORD,SDCC_Y_COORD,POPULATION_DATE_TIME,ISO_COUNTRY_CODE,HOTLIST_IND,BLACKLIST_IND,UPDATE_DATE_TIME,EVENT_TYPE_KEY,PROVIDER_DESCRIPTION,DM_IND,DIAL_DIGIT_OPERATOR_TYPE,CALL_DIRECTION_KEY,DIAL_DIGIT_DESCRIPTION,FORCE_RI_IND,TEST_CALL_IND;
when i am running this script it return's string beginning ":OLD.DIAL_..." is too long. maximum size is 239 characters.
how will i overcome from this situation.
i am passing parameter with .sql file

string beginning ":OLD.DIAL_..." is too long. maximum size is 239 characte. Be patient my friend....

String beginning ":OLD.DIAL_..." is too long. maximum size is 239 characte

@C:\Y\trigger.sql DIM_DIAL_DIGIT ctva_ra TRG_DIM_DIAL_DIGIT1
:OLD.DIAL_DIGIT_KEY,:OLD.BU_KEY,:OLD.NOP_ID_KEY,:OLD.SDCA_LOCATION_CODE,:OLD.TARGET_REGION_DESC,:OLD.TARGET_COUNTRY_CODE,:OLD.TARGET_COUNTRY_DESC,:OLD.LDCA_NAME,:OLD.SDCA_NAME,:OLD.LDCC_X_COORD,:OLD.LDCC_Y_COORD,:OLD.SDCC_X_COORD,:OLD.SDCC_Y_COORD,:OLD.POPULATION_DATE_TIME,:OLD.ISO_COUNTRY_CODE,:OLD.HOTLIST_IND,:OLD.BLACKLIST_IND,:OLD.UPDATE_DATE_TIME,:OLD.EVENT_TYPE_KEY,:OLD.PROVIDER_DESCRIPTION,:OLD.DM_IND,:OLD.DIAL_DIGIT_OPERATOR_TYPE,:OLD.CALL_DIRECTION_KEY,:OLD.DIAL_DIGIT_DESCRIPTION,:OLD.FORCE_RI_IND,:OLD.TEST_CALL_IND DIAL_DIGIT_KEY,BU_KEY,NOP_ID_KEY,SDCA_LOCATION_CODE,TARGET_REGION_DESC,TARGET_COUNTRY_CODE,TARGET_COUNTRY_DESC,LDCA_NAME,SDCA_NAME,LDCC_X_COORD,LDCC_Y_COORD,SDCC_X_COORD,SDCC_Y_COORD,POPULATION_DATE_TIME,ISO_COUNTRY_CODE,HOTLIST_IND,BLACKLIST_IND,UPDATE_DATE_TIME,EVENT_TYPE_KEY,PROVIDER_DESCRIPTION,DM_IND,DIAL_DIGIT_OPERATOR_TYPE,CALL_DIRECTION_KEY,DIAL_DIGIT_DESCRIPTION,FORCE_RI_IND,TEST_CALL_IND;
when i am running this script it return's string beginning ":OLD.DIAL_..." is too long. maximum size is 239 characters.
how will i overcome from this situation.
i am passing parameter with .sql file

Looks like you are trying to save the history data (with :OLD values).
If you are trying to generate a trigger at runtime, then you need a procedure which is able to loop through user_tab_columns for the given table and construct column strings for generation of triggers.
Then you can use EXECUTE IMMEDIATE to create the trigger.
Keep in mind that debugging such a procedure would be headache if you face any problems in creating the same.

MGP Tuning: MGP Processing taking too long

Hi All,
I have question here related to MGP Processing. MGP Processing is taking too long for us, close to 900 secs. Is there a way to tune and optimize this MGP Process. Right now we have only 3 users syncing and this kind of delay in Sync for users in testing Envt is not acceptable to the client. Is there a way to tune this MGP Process. I am aware of the Consperf process. Should I be running the Consperf for all the publication items to optimize their Sync process or should it be only for those publication items that are taking too long in the Compose/Apply process.
Thanks in advance for all suggestions.

Hi Rekounas,
what would be your recommendation for some 70 snapshots and 50 users? And is there any recommendation for mobile server? We have the mobile server on dedicated machine, which is quite old piece of HW. I presume that it should have just some amount of RAM available for caching of MGP data and that it shouldn't be CPU-power consuming much - is that right? At the monent the compose phase of MGP takes some 25-30 seconds per user when there's some new data to process...

MTU error (Path too long) with linux-3.6.2

I have a PC running 24/7, with an OpenVPN connection up all the time as well. I also have a (shared) ssh connection open, through said vpn. Every night an rsync job is ran, to backup some stuff over said VPN, through a shared ssh connection.
Starting a few days ago (Oct 17) I've had trouble with this, as in after rsync started, it would not be able to finish its job, getting "interrupted" (or, hanged) quite early on.
Looking in the journal, I can see error messages such as those (right after rsync starts, which happens at 02:23) :
Oct 17 02:23:05 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:06 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:06 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:06 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:06 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:07 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:09 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:13 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:22 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:23:39 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:24:13 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:25:20 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:27:21 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:29:21 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:31:21 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:33:22 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:35:22 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
Oct 17 02:37:22 arch.local openvpn@xxx[552]: read UDPv4 [EMSGSIZE Path-MTU=1460]: Message too long (code=90)
This eventually led to the ssh connection timing out, and the rsync job failing to complete.
Also, restarting OpenVPN seems to "fix" the issue, without the need to change any settings.
That's when I realized this started happening since upgrading the kernel to 3.6.2, so I then downgraded to 3.5.6 (Oct 19) and, since then, haven't had any issue.
So I'm thinking this is some kind of bug/regression in the 3.6 kernel, but I'm not really sure what to do now.
Note: I see 3.6.3 is out (and in testing), but only looked at the changelog so far (and didn't see anything that seem related to this issue?).

Thanks for your answers (and sorry about the delay).
I'm not sure how to read the error message actually, but I use default settings and `ip addr show` reports a MTU of 1500 indeed. Also, (on linux-3.6.2) I tried using OpenVPN's --mtu-test option to see what it would say (even though early on I never have a problem), and here it is:
NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1541,1541] remote->local=[1541,1541]
I'm nor really sure what it means, that I could (should?) use 1541 instead of 1500? And if so, how come it says I could go higher while I get errors with Path-MTU=1460 ? And actually, right before this result I do have a couple of those Path-MTU errors in the log, so I really don't know what to make of it, could it fail at 1460 but work higher? Does that even make sense?
I still don't know if it's really an MTU issue or not, since the kernel 3.5.6 isn't affected. Anyhow, I'll probably install 3.6.3 and see, hopefully it'll be back to normal.... if not I guess I'll have to try and set an MTU, though I'm not sure to what.
Also, would that require the OpenVPN server to have its MTU set that way as well (Since currently it also uses default settings, so MTU 1500) ?

Smartforms - Character field is too long

Hi
In my smartform I use a template, one of the fields is too long for the space it has in a template, and then it is shown too short. I want to show the whole field but in two lines, since there is no space in one line. Any suggestions in how I can trigger line feed.

Hi
If the cell of the template has more than 1 rows, the text should be written in two lines automatically.
Max

11gR2:crsctl, srvctl commands takes too long to respond

Hi,
I have successfully configured *11gR2 two node RAC on ASM on Win 2008 64bit.*
Everything work very well like connecting to database, querying database. Node restart also takes acceptable time to go down & restart the clusterware & database.
But when I execute crsctl status resource -t or srvctl status database -d db_name commands from any node takes 10-15min to give output.
They give output & everything completes successfully but takes too long to respond.
The questions are:
- If everything works fine then why crsctl, srvctl takes too long to respond?
- what could be blocking these command to gather clusterware and database status on all nodes?
- what additional info would be helpful that I can provide?

dag wrote:
I dont have this issue either. are you auto starting mpd?
that time is how long it is up in other words you opened it then closed it at that time
I'm not sure if you are referring to me or not, but in my screenshot I am timing the lag in ncmpcpp by pressing 'q' in the terminal during the delay, so it quits ncmpcpp immediately after the lag. The lag is longer for ncmpc because the interface loads before the program connects to mpd, so I have to stop it manually immediatly after it connects.
WonderWoofy wrote:I don't have this problem... if you are starting it as a systemd user service, maybe there is relevant information in the journal.
The journal did not reveal anything relevant sadly. I have now tried launching mpd without systemd, and the lag remains. I have also noticed that a small mpd programming project I am writing also experiences the same lag when it tries to connect to mpd.

Trigger delay too long

Similar Messages

Maybe you are looking for