 |
|
 |
I tried loading the DLL and received the following message when using it:
Could not load the DLL SQLAnnounceProc.dll, or one of the DLLs it references. Reason: 193(%1 is not a valid Win32 application.).
After doing some research it looks like I need the 64-bit version of the DLL. If someone has it could you let me know so that I can retrieve it. Thanks.
Mark Nadelson
|
|
|
|
 |
|
 |
Hi, I tried the dll and ran into some problems ( sql 2000 , I wrote a tiny console app to listen )
I found that if I try to send less than 3 characters it still sends 3 (some gargabe at the end)
with 4 - 7 characters, it always sends 7 , output parameter = "UnicastSend() - OK: 7 bytes sent"
With longer strings I found that it sends padded with 'old' data to the longest ever sent.
example
first step send 20 chars : 12345678901234567890
(output parameter = "UnicastSend() - OK: 20 bytes sent")
received ok : 12345678901234567890
second step send 10 chars : ABCDEFGHI
(output parameter = "UnicastSend() - OK: 20 bytes sent")
received not ok : ABCDEFGHI1234567890
Excuse me for my english pls, I hope you understand the problem.
Pablo75
|
|
|
|
 |
|
 |
I somehow fixed this adding a null character to the msg before calling the xp
SET @temp = @msg + CHAR(0)
Now, I'm having other problem , the dll fails to load on winnt, sql server on this machine also has a lower (or none) service pack applied than my test pc.
Pablo75
|
|
|
|
 |
|
 |
Recompile the project your self and then try again with the new dll. I compiled the project on either win2K or winxp - I don't remember
 Rod
|
|
|
|
 |
|
 |
Are you using the perl script I supplied with the project to receive? If not try it - receiving can be tricky.
 Rod
|
|
|
|
 |
|
 |
Hello,
This is urgent.
I have a Table ARTICLE_MASTER.
fields are item_code, activation_date.
I can different item_code for each article.
each article has a activation date.
select * from ARTICLE_MASTER
inner join
ARTICLE_MASTER ARTICLE_MASTER1
on ARTICLE_MASTER.item_code= ARTICLE_MASTER1.item_code
where ARTICLE_MASTER.activation_date < = getdate() and
ARTICLE_MASTER.end_date > = getdate() and
ARTICLE_MASTER.activation_date > ARTICLE_MASTER1.activation_date
order by article_master.item_code
I can have 4 rows for a single article - say 001- for Comb.
and for a given month say December, my acticle master can have 4 rows for article 001. with activation date and end date, for a single article i can have 4 rows.
say
ITEM_CODE ACTIVATION_DATE END_DATE PRICE
001 01/12/2005 31/12/2005 15
001 07/12/2005 31/12/2005 20
001 14/12/2005 31/12/2005 25
001 21/12/2005 31/12/2005 20
SO After comparison with my current date i have to decide which price to apply.
say on 2nd dec price should be 15
on 8th dec price should be 20
on 15th dec price should be 25
on 21-22th dec price should be 20
so i need to pick the appropriate row for a given date.
The query i have written above gives only the latest one say on 16th still it gives me 21st dec's row.
Please give me a solution for it.
its urgent
Amit Malik
.NET Developer
|
|
|
|
 |
|
 |
Tested fine on XP Pro and 2000 Server.
The 4th parameter seems to have a 256 character limit, kinda short for XML. UDP is supposed to go up to 60 000 I thought.
Is it the code or a protocol limit?
Thanks,
Bert
|
|
|
|
 |
|
 |
I would say neither. If you look in"SRVRETCODE SQLAnnounceProc(SRV_PROC* pSrvProc)" the length of the mesage is limited to 1024 chars. (char msg[1024]). You could change it to be larger but UDP is much less reliable with packet sizes more than around 2 - 4KB. You may not motice this unless your network is busy!
Examine your code for control chars or packets being fragmented. When you receive the msg make sure you can handle fragmented packets! Also if you are formatting the mesage in a var be sure to declare it big enough.
Thanks
Rod
Rod
|
|
|
|
 |
|
 |
Very good to know.
I found it very reliable for up to 256 characters. Yes, the var is big enough.
I did look at the code, saw the char msg[1024] and it didn't jibe with what I was receiving. I tried making it bigger, recompiled and got the same result (string is cropped at 256 characters).
I'm thinking of using VB.NET to check for control chars or packets being fragmented. Any references or suggestions how to?
Thanks for everything, very useful effort.
Cheers,
Bert
Software Developer,
http://www.quadmore.com
|
|
|
|
 |
|
 |
Hello again Rod,
I found the following reference which makes me suspect it might be a SQL Server 2000 limitation:
http://groups.google.ca/groups?hl=en&lr=&threadm=%23dtm3QYpEHA.3868%40TK2MSFTNGP15.phx.gbl&rnum=1&prev=/groups%3Fq%3D%252B%2522extended%2Bstored%2Bprocedure%2522%2B%252B256%2B%252BINPUT%26hl%3Den%26lr%3D%26selm%3D%2523dtm3QYpEHA.3868%2540TK2MSFTNGP15.phx.gbl%26rnum%3D1
I am using a varchar(8000) in the trigger calling the extended stored proc.
Could you retest the DLL on your end with a string longer than 256 characters for the msg parameter to check if it is an environment issue?
Thanks guys!
Thanks again,
Bert
Software Developer,
http://www.quadmore.com
|
|
|
|
 |
|
 |
I got a chance to test and am seeing the same thing. I will research this further!
CREATE PROCEDURE getTestTable
AS
BEGIN
SELECT * FROM TEST_TABLE
declare @status int
declare @ret varchar(513)
declare @temp as varchar(1024)
SET @temp = CAST('got ' + CAST( @@ROWCOUNT as varchar(16) ) + ' rows - 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890' as varchar(1024))
declare @ip varchar(32)
SET @ip = '127.0.0.1'
declare @port varchar(16)
SET @port = '15555'
exec @status = master.dbo.SQLAnnounceProc @ret OUTPUT, @ip, @port, @temp
END
GO
produces the output
04/26/2005 01:53:19 GMT received->got 6 rows - 123456789012345678901234567890123
45678901234567890123456789012345678901234567890123456789012345678901234567890123
45678901234567890123456789012345678901234567890123456789012345678901234567890123
4567890123456789012345678901234567890123456789012->255 bytes received from 127.0.0.1
Rod
|
|
|
|
 |
|
 |
Check out the new version! I had a bug and was using srv_paramdata() when I should have used srv_paraminfo() to retrieve the param values. srv_paramdata() will truncate params > 255 and has been superseded by the srv_paraminfo function! The other params still have the same 255 char limit but param 4, the msg, can be up to 1024 chars.
04/26/2005 03:34:40 GMT received->got 6 rows - 123456789012345678901234567890123
45678901234567890123456789012345678901234567890123456789012345678901234567890123
45678901234567890123456789012345678901234567890123456789012345678901234567890123
456789012345678901234567890123456789012345678901234567890_1234567890123456789012
34567890123456789012345678901234567890123456789012345678901234567890123456789012
34567890123456789012345678901234567890123456789012345678901234567890123456789012
34567890123456789012345678901234567890123456789012345678901234567890_12345678901
23456789012345678901234567890123456789012345678901234567890123456789012345678901
23456789012345678901234567890123456789012345678901234567890123456789012345678901
2345678901234567890123456789012345678901234567890123456789012345678901234567890_
12345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890
1234567890 END->1020 bytes received from 127.0.0.1
I did A LITTLE TESTING and everything seems ok.
Thanks for finding the bug.
Rod
Rod
|
|
|
|
 |
|
 |
Hello,
That's super. The file download link still points to the old code, however.
I did a text compare for the .c and .h files and nothing is different.
Yet!
Thanks much,
Bert
Software Developer,
http://www.quadmore.com
|
|
|
|
 |
|
 |
I uploaded the new zip file last night. I will upload it again now.
Rod
Rod
|
|
|
|
 |
|
 |
Thanks Rod,
This works as advertised!
I'll take two.
Cheers,
Bert
Software Developer,
http://www.quadmore.com
|
|
|
|
 |
|
 |
This is a very interesting code. Use UDP, and Extended SP, but until today I simply haven't the time to put this to concepts together.
It's gonna be hard for CodeProject to classify your code. Maybe it could be nice some SQL section for apps around DB Lib, Open Data Services, SQL DMO, etc.
Good job. Thanks
Sebastian
|
|
|
|
 |
|
 |
You really should elaborate on your internal C code as well in the article. I think people tend to rate articles very low if there isn't much content.
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
 |