Jump to content

Neil Barber

Member Since 17 Sep 2012
Offline Last Active May 20 2018 04:36 PM

Posts I've Made

In Topic: looking for a utility to read filedef and generate csv report

20 May 2018 - 04:36 PM

Hi Rob
Point your browser here and download the contents of "p4dump". Run whichever of "p4dump.bat" or "p4dump.sh" applies to your operating system and it'll display a complete synopsis of the command.
Something like

p4dump.sh -include "(?i)FILEDEF\.PRO" "/fully/qualified/path/to/the/bootstraps"

will be close.

Post process the output to remove the header, footer and far left (byte offset) column, and what you have left is tab separated values, nulls displayed as {null}, both of which you can substitute for whatever you need.

In Topic: alphacom

15 October 2017 - 07:49 PM

Hi Paul
AlphaCom is a SSH/Telnet client, right? If you're on Windows, I'd have a look at AutoHotkey, it's great for this sort of thing; lookup SetTimer, IfWinActive and SetCapsLockState




In Topic: DumpProIsamFile

03 May 2015 - 08:37 AM

Hi Ngoni


The exception is being thrown because the licence, under which this particular variant of the utility is distributed, is standalone, that is, it does not permit embedding in third-party applications; that's why it's free.




In Topic: Connecting to Multiple SQL DB's?

18 February 2014 - 07:05 AM

Watch out for SP_SERVEROPTION "collation_compatible". If it is not set to "true", a remote column referenced in the WHERE or ORDER BY clauses could result in the parent table being dragged back, in its entirity, to be processed locally.

In Topic: Connecting to Multiple SQL DB's?

17 February 2014 - 01:33 AM

MS SQL gives you two options, distributed (four part) queries, as has already been suggested, and OPENQUERY.

With a distributed query, the local server may be tempted to request a lot more data in order to do more processing locally, to generate the end result set, and the query might run slower than expected. With OPENQUERY, you stand a better chance of the remote server doing all the work for that part of the query.

Using a distibuted query is probably easier, in PROIV terms, as it can be accomplished by using the logical database name (from pro4.ini) in the physical file name. It's transparent, but that it obfuscates the fact that that logical file is actually a remote resource might not be a good thing, when it comes to later maintenance and the uninitiated. Side effects can involve SOSHOST_MUTEX waits under heavy load, while the local instance gathers statistics from the remote server to factor into the execution plan, or the wrong execution plan entirely, resulting in full table scans, and orders of magnitude more network traffic, if the account running the query can't access the histogram(s) http://msdn.microsof...y/ms175537.aspx


If the remote files are only being referenced in PROIV within full function SQL, or wholly native MS SQL objects, like stored procedures, have a look at OPENQUERY.