Date   

Re: Year End Issues, Gigaspaces Licenses and XPA

Moni‘s Gschichten <mobiel.muc@...>
 

What country are you based?
Am 23. Dez. 2020, 18:57 +0100 schrieb iluvmagic@...:

That's what I did a couple of years ago. They suggested the upgrade route. If you check out versions of magic xpa, the XAP license changes every certain cycle.

If you have any XPA 3.3 installed can you please tell me if your XAP license expiration does not end at Dec 31, 2020?

I  know not many people use the gigaspaces. Most of you are using the brokers that is why this issue is not common.


Re: Year End Issues, Gigaspaces Licenses and XPA

iluvmagic@...
 

That's what I did a couple of years ago. They suggested the upgrade route. If you check out versions of magic xpa, the XAP license changes every certain cycle.

If you have any XPA 3.3 installed can you please tell me if your XAP license expiration does not end at Dec 31, 2020?

I  know not many people use the gigaspaces. Most of you are using the brokers that is why this issue is not common.


Re: Year End Issues, Gigaspaces Licenses and XPA

mobiel.muc@...
 

why don't you talk to your branch contact? I can confirm support know it and can also be provided, has nothing todo with the version to upgrade

Am Di., 22. Dez. 2020 um 03:04 Uhr schrieb <iluvmagic@...>:

Three years ago, we encountered this issue.
Gigaspaces stopped working on Jan 1, 2018.
We are using Magic XPA 3.3a back then.
We called Magic for support but was not able to resolved it.
What they suggested was to reinstall the newest version of XPA.
Did not follow their advise totally since I don't know the consequences that might come with the new installation.

After a couple of days of research we finally noticed this. Gigaspaces uses a license file that is located at 
C:\Program Files (x86)\MSE\Magic xpa 3.3\GigaSpaces\xap-license.txt where there is an entry about license expiration "Expiration=2017-Dec-31"

What we did is install XPA 3.3d in a test server.
The new Gigaspaces license file xap-license.txt has an expiration entry of "Expiration=2020-Dec-31".
We replaced the xap-license.txt in our production server.
Gigaspaces worked smoothly.
We finally upgraded our server to XPA 3.3g a few months ago.
Everything is working smoothly up to this posting.


Now that it is that time of the year again and I have like 10 days left before - Expiration=2020-Dec-31.
I just want to ask if someone have resolve this issue another way?

Also if someone has XPA 3.3h or the latest version of Magic XPA, can u please post the XAP license expiration?

 

Thank you.

 

 

 

 

 

 

 

 

 


Re: DirectSQL removing the ORDER BY clause

Avgerinos
 

Hi everyone

This is to inform that, the solution that finally worked was to wrap the original SQL statement within an EXEC command. It only required to duplicate all single quotes in the query.
This solved the problems (maybe by "tricking" the gateway?) and the ORDER BY is no more removed.

BTW, I also tried changing the result database from SQLServer to Memory, with no luck.

Best Regards
Avgerinos

On 21/12/2020 6:51 μ.μ., Avgerinos wrote:

Hi Joseph and thank you for your reply

I don't have 3.3d installed, but I also tried on 3.3g & 3.3h and the problem persists.

I also noticed that if I have an index defined in Magic, similar to the ORDER-BY clause, Magic will not remove the ORDER BY from the direct SQL.

Regards
Avgerinos

On 18/12/2020 5:54 μ.μ., Joseph Feldman wrote:
I tried it on Magic 3.3d and the order by clause is not removed, and is working fine

Joseph

On Thu, Dec 17, 2020 at 2:22 PM Avgerinos <mento@...> wrote:
Hi magicians

In XPA 3.3c, I have a simple online task that uses a Direct SQL command to select the TOP-10 records from a table:
SELECT TOP 10  [product], [price], [volume], [value]    FROM [dbo].[orders]    WHERE [product] = 'TEST'   ORDER BY [volume] DESC

When I run the program I get a different result set compared to what I 'm getting when I run the query in the Management Studio (MSSQL 2014).
By checking via the SQL profiler, I found out that Magic is removing the ORDER BY clause when executing the command.

Anyone experienced something similar? Any way to avoid?

Best regards
Avgerinos




Year End Issues, Gigaspaces Licenses and XPA

iluvmagic@...
 
Edited

Three years ago, we encountered this issue.
Gigaspaces stopped working on Jan 1, 2018.
We were using Magic XPA 3.3a back then.
We called Magic for support but was not able to resolved it.
What they suggested was to reinstall the newest version of XPA.
Did not follow their advise totally since I don't know the consequences that might come with the new installation.

After a couple of days of research we finally noticed this. Gigaspaces uses a license file that is located at 
C:\Program Files (x86)\MSE\Magic xpa 3.3\GigaSpaces\xap-license.txt where there is an entry about license expiration "Expiration=2017-Dec-31"

What we did is install XPA 3.3d in a test server.
The new Gigaspaces license file xap-license.txt has an expiration entry of "Expiration=2020-Dec-31".
We replaced the xap-license.txt in our production server.
Gigaspaces worked smoothly.
We finally upgraded our server to XPA 3.3g a few months ago.
Everything is working smoothly up to this posting.


Now that it is that time of the year again and I have like 10 days left before - Expiration=2020-Dec-31.
I just want to ask if someone have resolve this issue another way?

Also if someone has XPA 3.3h or the latest version of Magic XPA, can u please post the XAP license expiration?

 

Thank you.

 

 

 

 

 

 

 

 

 


Re: Capture Field Value with Function Key

sherman levine
 

Um.... remnants

On 12/21/2020 5:45 PM, sherman levine wrote:

Never feel foolish.
It's always better to leave the remanants around, so you know the path you've taken :-)



On 12/21/2020 5:05 PM, Mike McMillin wrote:
As always you are a absolutely correct.  I don't know why I had it there I was going to use it debugging, but then didn't because it was working.

Now I feel foolish, 




Re: Capture Field Value with Function Key

sherman levine
 

Never feel foolish.
It's always better to leave the remanants around, so you know the path you've taken :-)



On 12/21/2020 5:05 PM, Mike McMillin wrote:

As always you are a absolutely correct.  I don't know why I had it there I was going to use it debugging, but then didn't because it was working.

Now I feel foolish, 



Re: "Included Columns" in index definition? (MSSQL)

Tim Downie
 

Hi
If you use virtual indexs with any sort of decent size database/users - you will run into problems sooner or later.

Indexs in magic virtual or real - tell magic to place an order by after the sql select statement  - if you have a lot of data and do an order by without this matching a REAL index in sql (eg a virtual index)
you will have performance issues




From: main@magicu-l.groups.io <main@magicu-l.groups.io> on behalf of sherman levine <sherman.levine@...>
Sent: Monday, 21 December 2020 8:52 PM
To: main@magicu-l.groups.io <main@magicu-l.groups.io>
Subject: Re: [magicu-l] "Included Columns" in index definition? (MSSQL)
 
Most of the time, there's no DBA, and I get just one shot at the process, so If I think the real index might be used often - particularly in a batch task, then I just create it at the start.
Sherm

On 12/21/2020 7:37 AM, Andy Jerison wrote:

That's how the process should work, minus the fussing. 

On Mon, Dec 21, 2020, 07:14 sherman levine <sherman.levine@...> wrote:
Interesting. I do add virtual indexes to tables I don't control (for the reasons below), however I was recently fussed at by a DBA who informed me that a Magic query was slowing his system, and he created a real index for me (which was identical to my virtual index) and told me I should use it please.

Sherm


On 12/20/2020 11:13 PM, Andy Jerison wrote:
It's okay to define indexes for SQL databases. If you let Magic create the tables, you should set them all as virtual indexes. I'd say the best practice is to make all indexes virtual. Magic will include ORDER BY clauses on selected indexes and the database will use its optimizer to process the queries efficiently. 

Maintaining a lot of indexes imposes serious overhead on the database. Most indexes we had to create in Pervasive aren't necessary in a decent SQL database. 

You should instead use the database's tuning tools to create indexes once your db is populated.

Andy 

On Sun, Dec 20, 2020, 13:42 sherman levine <sherman.levine@...> wrote:
Andy,

My own answer would be that I define an index whenever I want to see a subset of records displayed in a specific sequence and I don't want to do a runtime sort.

For example, show all the records created by user XXXX in datetime sequence.

Similarly, I define an index when I want to return a specific record in a link. (show me the most recent record created by user XXXX)

Is that inappropriate?

Thanks

Sherm

On 12/20/2020 1:30 PM, Andy Jerison wrote:
Why are you defining an index? 

On Sun, Dec 20, 2020, 12:46 Avgerinos <mento@...> wrote:
Hi magicians :-)

When defining an Index In the Data-Repository of XPA (v.3 or 4) and
besides the "Index Key Columns",
is there any way to specify the "Included Columns" when defining an
index for an MSSQL table?

Thanks in advance
Avgerinos









Re: Capture Field Value with Function Key

Mike McMillin
 

As always you are a absolutely correct.  I don't know why I had it there I was going to use it debugging, but then didn't because it was working.

Now I feel foolish, 


Re: "Included Columns" in index definition? (MSSQL)

sherman levine
 

Most of the time, there's no DBA, and I get just one shot at the process, so If I think the real index might be used often - particularly in a batch task, then I just create it at the start.
Sherm

On 12/21/2020 7:37 AM, Andy Jerison wrote:

That's how the process should work, minus the fussing. 

On Mon, Dec 21, 2020, 07:14 sherman levine <sherman.levine@...> wrote:
Interesting. I do add virtual indexes to tables I don't control (for the reasons below), however I was recently fussed at by a DBA who informed me that a Magic query was slowing his system, and he created a real index for me (which was identical to my virtual index) and told me I should use it please.

Sherm


On 12/20/2020 11:13 PM, Andy Jerison wrote:
It's okay to define indexes for SQL databases. If you let Magic create the tables, you should set them all as virtual indexes. I'd say the best practice is to make all indexes virtual. Magic will include ORDER BY clauses on selected indexes and the database will use its optimizer to process the queries efficiently. 

Maintaining a lot of indexes imposes serious overhead on the database. Most indexes we had to create in Pervasive aren't necessary in a decent SQL database. 

You should instead use the database's tuning tools to create indexes once your db is populated.

Andy 

On Sun, Dec 20, 2020, 13:42 sherman levine <sherman.levine@...> wrote:
Andy,

My own answer would be that I define an index whenever I want to see a subset of records displayed in a specific sequence and I don't want to do a runtime sort.

For example, show all the records created by user XXXX in datetime sequence.

Similarly, I define an index when I want to return a specific record in a link. (show me the most recent record created by user XXXX)

Is that inappropriate?

Thanks

Sherm

On 12/20/2020 1:30 PM, Andy Jerison wrote:
Why are you defining an index? 

On Sun, Dec 20, 2020, 12:46 Avgerinos <mento@...> wrote:
Hi magicians :-)

When defining an Index In the Data-Repository of XPA (v.3 or 4) and
besides the "Index Key Columns",
is there any way to specify the "Included Columns" when defining an
index for an MSSQL table?

Thanks in advance
Avgerinos









Re: Capture Field Value with Function Key

sherman levine
 

Mike,
Glad you got it working
What does the lastpark(1) expression in RS do?  It should return the control name, but it's not clear to me why you'd need that
Sherm

On 12/21/2020 3:41 PM, Mike McMillin wrote:

Oops, I reversed the last 2 statement.

LastPark(1) in Record Suffix.
KbPut('Ctrl+Home'KBD&Trim(Str(CV,'########.##'))) in Task Suffix



Re: Capture Field Value with Function Key

Mike McMillin
 

Oops, I reversed the last 2 statement.

LastPark(1) in Record Suffix.
KbPut('Ctrl+Home'KBD&Trim(Str(CV,'########.##'))) in Task Suffix


Re: Capture Field Value with Function Key

Mike McMillin
 

Thanks for the help, I got it to work.  You guys are great.

EditGet it Main
VarAttr(THIS()) in main.  This is what really help me figure it out.  Thanks Sherm
Call a pgm from main pgm with these as expressions in the parameters
Do the math
KbPut('Ctrl+Home'KBD&Trim(Str(CV,'########.##'))) in record suffix
LastPark(1) in Task Suffix.


Re: DirectSQL removing the ORDER BY clause

Avgerinos
 

Hi Joseph and thank you for your reply

I don't have 3.3d installed, but I also tried on 3.3g & 3.3h and the problem persists.

I also noticed that if I have an index defined in Magic, similar to the ORDER-BY clause, Magic will not remove the ORDER BY from the direct SQL.

Regards
Avgerinos

On 18/12/2020 5:54 μ.μ., Joseph Feldman wrote:

I tried it on Magic 3.3d and the order by clause is not removed, and is working fine

Joseph

On Thu, Dec 17, 2020 at 2:22 PM Avgerinos <mento@...> wrote:
Hi magicians

In XPA 3.3c, I have a simple online task that uses a Direct SQL command to select the TOP-10 records from a table:
SELECT TOP 10  [product], [price], [volume], [value]    FROM [dbo].[orders]    WHERE [product] = 'TEST'   ORDER BY [volume] DESC

When I run the program I get a different result set compared to what I 'm getting when I run the query in the Management Studio (MSSQL 2014).
By checking via the SQL profiler, I found out that Magic is removing the ORDER BY clause when executing the command.

Anyone experienced something similar? Any way to avoid?

Best regards
Avgerinos



Re: "Included Columns" in index definition? (MSSQL)

Andy Jerison
 

That's how the process should work, minus the fussing. 


On Mon, Dec 21, 2020, 07:14 sherman levine <sherman.levine@...> wrote:
Interesting. I do add virtual indexes to tables I don't control (for the reasons below), however I was recently fussed at by a DBA who informed me that a Magic query was slowing his system, and he created a real index for me (which was identical to my virtual index) and told me I should use it please.

Sherm


On 12/20/2020 11:13 PM, Andy Jerison wrote:
It's okay to define indexes for SQL databases. If you let Magic create the tables, you should set them all as virtual indexes. I'd say the best practice is to make all indexes virtual. Magic will include ORDER BY clauses on selected indexes and the database will use its optimizer to process the queries efficiently. 

Maintaining a lot of indexes imposes serious overhead on the database. Most indexes we had to create in Pervasive aren't necessary in a decent SQL database. 

You should instead use the database's tuning tools to create indexes once your db is populated.

Andy 

On Sun, Dec 20, 2020, 13:42 sherman levine <sherman.levine@...> wrote:
Andy,

My own answer would be that I define an index whenever I want to see a subset of records displayed in a specific sequence and I don't want to do a runtime sort.

For example, show all the records created by user XXXX in datetime sequence.

Similarly, I define an index when I want to return a specific record in a link. (show me the most recent record created by user XXXX)

Is that inappropriate?

Thanks

Sherm

On 12/20/2020 1:30 PM, Andy Jerison wrote:
Why are you defining an index? 

On Sun, Dec 20, 2020, 12:46 Avgerinos <mento@...> wrote:
Hi magicians :-)

When defining an Index In the Data-Repository of XPA (v.3 or 4) and
besides the "Index Key Columns",
is there any way to specify the "Included Columns" when defining an
index for an MSSQL table?

Thanks in advance
Avgerinos








Re: "Included Columns" in index definition? (MSSQL)

sherman levine
 

Interesting. I do add virtual indexes to tables I don't control (for the reasons below), however I was recently fussed at by a DBA who informed me that a Magic query was slowing his system, and he created a real index for me (which was identical to my virtual index) and told me I should use it please.

Sherm


On 12/20/2020 11:13 PM, Andy Jerison wrote:

It's okay to define indexes for SQL databases. If you let Magic create the tables, you should set them all as virtual indexes. I'd say the best practice is to make all indexes virtual. Magic will include ORDER BY clauses on selected indexes and the database will use its optimizer to process the queries efficiently. 

Maintaining a lot of indexes imposes serious overhead on the database. Most indexes we had to create in Pervasive aren't necessary in a decent SQL database. 

You should instead use the database's tuning tools to create indexes once your db is populated.

Andy 

On Sun, Dec 20, 2020, 13:42 sherman levine <sherman.levine@...> wrote:
Andy,

My own answer would be that I define an index whenever I want to see a subset of records displayed in a specific sequence and I don't want to do a runtime sort.

For example, show all the records created by user XXXX in datetime sequence.

Similarly, I define an index when I want to return a specific record in a link. (show me the most recent record created by user XXXX)

Is that inappropriate?

Thanks

Sherm

On 12/20/2020 1:30 PM, Andy Jerison wrote:
Why are you defining an index? 

On Sun, Dec 20, 2020, 12:46 Avgerinos <mento@...> wrote:
Hi magicians :-)

When defining an Index In the Data-Repository of XPA (v.3 or 4) and
besides the "Index Key Columns",
is there any way to specify the "Included Columns" when defining an
index for an MSSQL table?

Thanks in advance
Avgerinos








Locate Message

Pavel Mencl
 

Hi,
I face a request to redirect Locate's "Record not found" message from the status bar to a message box. Is there an easy way I just don't recall?
Thanks
Pavel
 


Re: "Included Columns" in index definition? (MSSQL)

Avgerinos
 

Hi Andy & Sherman

I prefer to define all tables (fields, indices and related attributes) with the Magic Data Dictionary.
Having all the app design and logic defined and primarily stored in one place (Magic), helped me keep a good control of my numerous apps during the last 35 years.
If I need an extra feature which is not directly supported by Magic, I always try to find a way to define within the Studio, instead of using e.g. the Management Studio (in the case of MS-SQL).
And this happens very rarely, since I always avoid "acrobatics" when designing a database.

My current need is to add an "Included Column" in addition to the "Indexed Columns of an MSSQL table.
"Included Columns" are the ones that are stored in the index (for speed optimization purposes only) without participating in it.
This can be easily done in Management studio, but still I would prefer this to be done within Magic.

My question to the group came because I was hoping that there is some "Additional DB Information" solution or something similar.

Thank you both for your replies
Best Regards
Avgerinos


On 21/12/2020 6:13 π.μ., Andy Jerison wrote:

It's okay to define indexes for SQL databases. If you let Magic create the tables, you should set them all as virtual indexes. I'd say the best practice is to make all indexes virtual. Magic will include ORDER BY clauses on selected indexes and the database will use its optimizer to process the queries efficiently. 

Maintaining a lot of indexes imposes serious overhead on the database. Most indexes we had to create in Pervasive aren't necessary in a decent SQL database. 

You should instead use the database's tuning tools to create indexes once your db is populated.

Andy 

On Sun, Dec 20, 2020, 13:42 sherman levine <sherman.levine@...> wrote:
Andy,

My own answer would be that I define an index whenever I want to see a subset of records displayed in a specific sequence and I don't want to do a runtime sort.

For example, show all the records created by user XXXX in datetime sequence.

Similarly, I define an index when I want to return a specific record in a link. (show me the most recent record created by user XXXX)

Is that inappropriate?

Thanks

Sherm

On 12/20/2020 1:30 PM, Andy Jerison wrote:
Why are you defining an index? 

On Sun, Dec 20, 2020, 12:46 Avgerinos <mento@...> wrote:
Hi magicians :-)

When defining an Index In the Data-Repository of XPA (v.3 or 4) and
besides the "Index Key Columns",
is there any way to specify the "Included Columns" when defining an
index for an MSSQL table?

Thanks in advance
Avgerinos








Re: "Included Columns" in index definition? (MSSQL)

Andy Jerison
 

It's okay to define indexes for SQL databases. If you let Magic create the tables, you should set them all as virtual indexes. I'd say the best practice is to make all indexes virtual. Magic will include ORDER BY clauses on selected indexes and the database will use its optimizer to process the queries efficiently. 

Maintaining a lot of indexes imposes serious overhead on the database. Most indexes we had to create in Pervasive aren't necessary in a decent SQL database. 

You should instead use the database's tuning tools to create indexes once your db is populated.

Andy 


On Sun, Dec 20, 2020, 13:42 sherman levine <sherman.levine@...> wrote:
Andy,

My own answer would be that I define an index whenever I want to see a subset of records displayed in a specific sequence and I don't want to do a runtime sort.

For example, show all the records created by user XXXX in datetime sequence.

Similarly, I define an index when I want to return a specific record in a link. (show me the most recent record created by user XXXX)

Is that inappropriate?

Thanks

Sherm

On 12/20/2020 1:30 PM, Andy Jerison wrote:
Why are you defining an index? 

On Sun, Dec 20, 2020, 12:46 Avgerinos <mento@...> wrote:
Hi magicians :-)

When defining an Index In the Data-Repository of XPA (v.3 or 4) and
besides the "Index Key Columns",
is there any way to specify the "Included Columns" when defining an
index for an MSSQL table?

Thanks in advance
Avgerinos







Re: "Included Columns" in index definition? (MSSQL)

sherman levine
 

Andy,

My own answer would be that I define an index whenever I want to see a subset of records displayed in a specific sequence and I don't want to do a runtime sort.

For example, show all the records created by user XXXX in datetime sequence.

Similarly, I define an index when I want to return a specific record in a link. (show me the most recent record created by user XXXX)

Is that inappropriate?

Thanks

Sherm

On 12/20/2020 1:30 PM, Andy Jerison wrote:

Why are you defining an index? 

On Sun, Dec 20, 2020, 12:46 Avgerinos <mento@...> wrote:
Hi magicians :-)

When defining an Index In the Data-Repository of XPA (v.3 or 4) and
besides the "Index Key Columns",
is there any way to specify the "Included Columns" when defining an
index for an MSSQL table?

Thanks in advance
Avgerinos






2721 - 2740 of 196382